CTO - Optimize Your Software Development Estimations!

Let's try to compare three different estimation techniques: Story Points with Planning Poker, Slices and Quick Function Point Estimation.

Let's define them in a short form.

Story Points with Planning Poker

  1. Identify User Stories: User stories, which describe a feature or requirement from the user's perspective, are identified for the project.

  2. Discuss the Stories: The development team discusses each user story to understand its requirements and complexities. This is a crucial step for ensuring shared understanding.

  3. Estimate with Poker: Each team member privately selects a card that represents their estimate of the effort required to complete the user story. This is done in "story points", which are a unit of measure that captures the complexity, effort, and uncertainty of the task.

  4. Reveal and Discuss: All team members reveal their cards simultaneously, promoting honest estimates. If there's a large discrepancy between the estimates, the team discusses the user story again, particularly focusing on why some members gave higher or lower estimates.

  5. Consensus on Story Points: The team repeats the estimation process until a consensus is reached on the number of story points for the user story.

Slice units

  1. Execute Event Modeling, and make sure you have all alternative scenarios.

  2. Whenever the system memories slice of the story; When you see a unique pair command -> event, or [external] event -> event, based on their name, not data, count it as one write-slice.

  3. Whenever the system draws conclusions/views based on its factful memory; When you see a unique read-model by name, count it as 1 read-slice.

If you are familiar with DDD but not with Event Modeling, this might give you hit of the slice unit:

  • Command handler is one write slice (in worst case scenario, it might encapsulate few invariants of a bigger aggregate (rare)).

  • Translation of external event into the internal event is counted as one write-slice.

  • Read-Model is one read slice, even if many events construct it.

  • A DDD policy translates into a processor, so we'll have 2 slices: read-model for a TODO list and one command-handler.

Quick Function Point Estimation

  1. Identify Functions: The system's functionalities are identified. These are classified as either user transactions (External Inputs, External Outputs, External Inquiries) or data storage types (Internal Logical Files and External Interface Files).

  2. Rate Complexity: Each function is rated on a scale (usually from low to high) based on its complexity, considering factors like data elements, file types involved, and processing logic.

  3. Calculate Function Points: Each function's complexity rating is then converted into function points using predefined weightings.

  4. Estimate Effort: The total function points are then used to estimate the effort required for the project, often using historical data or industry benchmarks.

Comparison

Metric
Story Points with Poker
Slices Estimation
Quick Function Point Estimation
Accuracy Can vary, dependent on team experience High, unless business & impacts are not explored/discovered. High, dependent on estimator's experience
Effort Moderate, requires regular meetings Low-Moderate, depends on UX fidelity High, detailed system analysis needed
Scalability Scales well with project size and complexity Scales well with project size and complexity Scales well with complex projects
Transparency Less transparent to non-technical stakeholders High, countable slice units Moderate, technical understanding needed
Objectivity Subjective, relies on consensus Objective Objective
Flexibility Moderate, easily adaptable, but requires Team High, rough estimation to changes can be done by business-people Less, changes may need significant re-estimation
Predictability Good, uses past velocity Good, uses past team or individual performance Good, uses historical data
Risk Management Dependent on team's expertise Systematic during Event Modeling Evaluates technological risk, not idea/modelled behaviour risk
Applicability Applicable to any, especially Agile, projects Best for Event-Driven, CQRS, Event Sourcing, and DDD projects Best for ERP-like, with anemic-domain, ESB and RDBMs systems
Learning Curve Moderate, needs experience with planning poker Low, learning Event Modeling is easy, doesn't require DDD. High, needs understanding of function points and estimation process
Speed of Estimation Moderate, dependent on number of stories and team discussion Very quick for first pass, moderate for detailed Slow, detailed system analysis required
Contract type, methodology Any, except fixed-price; agile, lean Any; agile, lean or waterfall Fixed-price, waterfall

Q & A

Question
Story Points with Poker
By-The-Slice Estimation
Quick Function Point Estimation
Can I estimate the budget Arguably yes, but it's challenging Yes Yes
How do I know it's accurate? Engineers have reached a consensus. We trust their professional judgment. Confrontation regarding design rarely happens. Everyone sees and understands the complexity, including Business people. Only qualified engineers can calculate points.
Stakeholder: "Why so long does it take to implement this User-Story / Feature?" Because the collective engineering team asserts it. We trust their professional judgment. You can count frames (slices) from Event Modeling and assess it for yourself. Because highly qualified principal engineer(s) assert it. Their expertise lends credibility to their estimation.
How do I know when certain story will be delivered? Arguably, you might use team velocity (effort/time) to estimate if the team has the capacity to deliver it in the next sprint. We can use the performance of a team or individuals to estimate the timeline. Technology and non-functional requirements might influence it, but they can be evaluated. We rely on the history of similar projects or team performance to estimate time.
What can go wrong? Influence, bias, gaming the system, Teams or individuals may artificially inflate or deflate their estimates for various reasons It's rare, but some parts of the system that don't strictly process information may require fallback to other estimation techniques. We rely heavily on the expert knowledge of the person doing the estimates.
Is cost tied to business value? Not directly, it depends on PM It should be, defined metric and impact(s) corresponds directly to parts of stories we estimate No
What technology stack is preferable? Any Event Store, Kafka, Marten, Elastic Search, MongoDB, GRPC SQL-DBs, ESB, HTTP REST

Summary

As a CTO, do you find traditional methods like Story Points with Planning Poker and Quick Function Point Estimation sometimes fall short in providing transparency and require significant effort, particularly in the case of QFPE? Allow us to introduce an alternative.

Discover an alternative to traditional methods: our article Managing Costs. Learn about the 'slices' methodology, Cynefin framework, the influence of non-functional requirements, and more.

Send question
Got a tech puzzle to solve?

Drop it here and we'll unpack it with you, dishing out thorough tech insights.
Schedule meeting
More of a chat person?

Ping us for a 15-minute talk and we can dive into the tech sea together ;)