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
Identify User Stories: User stories, which describe a feature or requirement from the user's perspective, are identified for the project.
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.
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.
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.
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
Execute Event Modeling, and make sure you have all alternative scenarios.
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.
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
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).
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.
Calculate Function Points: Each function's complexity rating is then converted into function points using predefined weightings.
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.
Drop it here and we'll unpack it with you, dishing out thorough tech insights.
Ping us for a 15-minute talk and we can dive into the tech sea together ;)