In the first part of this series on estimating product deliverables, we explored common agile estimating techniques like story points, planning poker, and t-shirt sizing. While those methods are great for arriving at initial sizing and gauging relative complexity, product teams often need more precise and data-driven forecasts to more accurately estimate deliverables.
In this post, we’ll briefly explore several methods that can help add more rigor and confidence to help accurately estimate product deliverables:
- Bucket system – Quickly categorize features into relative size buckets
- Analogous estimating – Leverage historical data as a benchmark
- Comparative sizing – Determine relative complexity through comparison
- Complexity points – Gauge effort based on technical factors
- Affinity mapping – Cluster to compare the size of groups
- Three-point estimating – Consider optimistic, pessimistic, and likely scenarios
- Expert judgment – Tap into experience and knowledge from specialists
While several of these may sound like traditional project management approaches to estimating, product managers can also adapt them during agile sprints for estimating product deliverables and to gain additional precision around staffing needs, dependency mapping, and delivery timelines.
Combining the collaborative techniques from Part 1 with some of the methods outlined in this post, can potentially help product managers and product owners more accurately estimate deliverables.
Let’s explore how each can contribute value to the planning process.
Bucket System
In this method, user stories are grouped into buckets based on their size or complexity. The buckets can be predefined ranges like small, medium, or large, or can be custom-defined based on team-specific criteria. Like the T-Shirt Sizing method discussed in the previous post, this approach helps in quickly categorizing user stories and creating a high-level estimation.
Like T-Shirt sizing, this method provides only quick rough estimates, therefore as more accurate estimations are required, the team may need to follow up with other techniques, such as Planning Poker or Story Points during sprint planning or backlog refinement sessions.
Analogous Estimating
Analogous estimating, also known as top-down estimating, relies on historical data or expert judgment to estimate the duration, effort, or cost of a deliverable or task. This technique involves comparing the current project with similar past deliverables, using that data as a benchmark to guide estimation. It provides a quick and relatively simple method; however, it can be less accurate if there are significant differences between the deliverables being compared.
Comparative Sizing
Comparative Sizing provides a quick estimation approach that relatively ranks user stories based on effort and complexity through direct comparison against each other.
During a backlog refinement session, the product owner presents a prioritized list of stories to be estimated by the team. Team members select two stories at a time and analyze their scopes to determine which story seems more complex or challenging to implement.
The chosen story is marked as larger/higher effort. The other story becomes the baseline for the next comparison. This continues until all stories have been compared multiple times against others to produce a relative ordering from small to large.
The directly comparative nature brings clarity on scope differences. Comparing two stories side-by-side builds consensus faster than independently trying to assign abstract points or values.
However, Comparative Sizing typically works best for a limited set of stories. As the backlog grows, it becomes increasingly cumbersome to compare all combinations of stories.
Teams may use Comparative Sizing on a subset of high priority stories during backlog refinement before employing additional estimation techniques for the larger backlog. It provides fast relative scoping to inform sprint planning and early roadmapping.
Complexity Points
Complexity Points are an agile estimating approach similar to Story Points, but with the key difference that the scale refers specifically to the complexity and anticipated implementation challenge of each user story.
During backlog refinement, the team analyzes factors like technical risk, solution complexity, unknown dependencies, and potential code impacts when assigning complexity points. The discussion focuses on how tricky or complex each user story will be to implement rather than just its overall scope or size.
For example, a large user story adding straightforward database fields may be a lower complexity value like 5 points. However, a small story requiring complex machine learning algorithms or interfaces with multiple systems may be rated 13 points or higher.
The complexity scale uses a nonlinear sequence like the Fibonacci series (1, 2, 3, 5, 8, 13, etc.) to account for the inherent uncertainty in early analysis. The higher the number, the more complex and risky the team believes implementation will be.
Over iterations, the team derives velocity metrics based on completed complexity points. This helps forecast the amount of complexity they can handle per sprint. It also aids planning by providing data on how many complex user stories (8+ points) versus simpler ones (1-3 points) the team can complete.
Unlike Story Points, Complexity Points keep the focus on technical implementation challenges. This provides helpful insight into risk management, technical planning, and developing team skills to take on more complex work over time.
Affinity Mapping
Affinity Mapping provides a collaborative technique for agile teams to categorize user stories into groupings that represent similar levels of effort or complexity. This enables high-level estimation by comparing the relative sizes of the grouped clusters.
During a backlog refinement or planning session, the product owner supplies the list of user stories to be estimated. The team works together to review the stories and identify natural groupings based on shared characteristics like complexity, functionality, dependencies, or components affected.
For example, simpler stories may form one cluster while more complex, technical stories are grouped in another. The team names each cluster and continues sorting all the stories until affinity groups emerge.
Once all stories are grouped, the team can compare the relative sizes and complexities of the clusters. If the complex cluster is considerably smaller than the simple cluster, they know there are fewer complex stories to implement. The clustered mapping provides a visualization of scope differences.
Affinity Mapping jumpstarts estimation by providing a fast, collaborative way to categorize backlog items before assigning detailed story points or time estimates. It takes advantage of the team’s collective knowledge to rapidly identify patterns and similarities between stories.
The visual clustering gives instant insights into the scope mix and where complexities lie within the overall body of work. This informs planning and high-level roadmapping before the team dives into finer-grained estimation techniques.
Three-Point Estimating (PERT)
Often applied to more traditional project planning, three-point estimating is a technique that considers three estimates for each task or project: the optimistic estimate (best-case scenario), the pessimistic estimate (worst-case scenario), and the most likely estimate (realistic scenario).
Once these three estimates are available, the next step is to calculate a weighted average that considers all three scenarios. A common method for this is to use the Program Evaluation and Review Technique (PERT) formula, which takes the three estimates and applies the following formula:
Estimated Duration = (Optimistic + 4 * Most Likely + Pessimistic) / 6
The PERT formula places more weight on the most likely estimate, reducing the impact of extreme scenarios (optimistic or pessimistic) that may be less likely to occur. This weighted average provides a more balanced and probabilistic estimate that accounts for uncertainties and risks associated with the task or project.
Expert Judgment
Lastly, expert judgment involves seeking input and insights from subject matter experts, or experienced individuals who have knowledge and expertise in the area being estimated. Experts can provide valuable insights based on their experience, domain knowledge, and historical data, helping to refine estimates and account for specific project complexities or risks.
Conclusion
Estimating product deliverables is crucial yet challenging. By leveraging a combination of agile and traditional techniques, product managers can develop more accurate and reliable forecasts.
As discussed in Part I of this series, story points, planning poker, and t-shirt sizing enable quick relative sizing and team alignment. However, complixity points, affinity mapping, three-point analysis, and other methods discussed in this post bring in addition data and rigor to calibrate estimates.
While no singular approach can eliminate all uncertainty, having a toolkit of estimating techniques empowers product managers to triangulate on Delivery timelines and quantify efforts.
Estimating product deliverables is an iterative process. Revisit and refine estimates as more information becomes available. Track actual data over time to improve the calibration of estimates.
By blending collaborative and data-driven estimating practices, product managers can accurately estimate deliverables and develop actionable roadmaps, optimize workflows, and deliver greater value to customers. Precise estimating is a journey, but these techniques will help you continuously improve forecasting and exceed customer expectations.