As more of our clients adopt Agile methods, they often wonder how SLIM-Estimate fits into the Agile planning process? It’s not uncommon for teams to claim that Agile makes estimation obsolete. But regardless of which features end up in a particular release, businesses still need to know how much functionality can be delivered within a given schedule and budget. Because I have been working with more customers to estimate Agile projects, the first Agile planning and analysis practice suggested by Ellen Gottesdiener & Mary Gorman got my attention ‒ Use Three Planning Horizons: Now-View, Pre-View, and Big-View. Simply stated, each level of the view hierarchy represents more fine-grained planning and analysis:
- Big-View – general idea; how the product will fit in with other products
- Pre-View – enough detail to start planning the next release
- Now-View – delivery team analyzes and estimate activities needed
Their statement, "we don’t think of agile as a methodology per se. Rather, it’s a disciplined discovery and delivery framework (emphasis added)" is consistent with QSM's approach to estimating Agile projects. Macro estimation techniques allow the business to allocate resources to product development efforts by identifying the number of releases to be built during the next budget cycle, which corresponds to the Big-View horizon. More detailed release planning is performed later in the process, using the prioritized product backlog to determine delivery goals for each iteration.
Product Backlog Prioritization (image via Roman Pichler)
Estimates are, by definition, uncertain. In our SLIM Training Classes, we emphasize the importance of factoring this uncertainty into estimates explicitly. We use Boehm and McConnell'si familiar Cone of Uncertainty to demonstrate that uncertainty is greatest early in the project life cycle when little data is available. As the development team makes progress in decomposing requirements and building out the design, more knowledge is acquired and uncertainty (and therefore risk) is reduced. It occurred to me that the Agile practice of defining and managing the product backlog aligns with this phenomenon (documented in many publications, like the illustration above from Roman Pichler). Gottesdiener and Gorman's view hierarchy also aligns, confirming the reality that earlier estimates will encompass a higher degree of uncertainty. The figure below shows the alignment of these three concepts.
How Product Backlog Aligns with the Cone of Uncertainty
These diagrams neatly align when there is a consistent definition of a project or program. If we ignore the Waterfall development time slices on the cone of uncertainty and let it represent the disciplined discovery and delivery of the Agile methodology, we see the need to continue estimation and planning throughout the life cycle.
Different SLIM Suite products can be utilized at different points in the Agile process, matching the tool to the data available and the tasks to be performed at each stage of the project lifecycle:
- Big-View. Early on, product managers must take the backlog of features and make a business case for the development budget. The prioritized list of features lets him sketch out a proposed release schedule. SLIM-Estimate can be used at the Big-View level to establish the number of stories or features that will fit into a typical release timeframe.
- Pre-View. Once high level requirements have been fleshed out enough to support a more detailed size estimate in story points, both SLIM-Estimate and SLIM-MasterPlan can be used to fine-tune the estimate.
- Now-View. The Now-View is supported by SLIM-Control, where buildup charts, burn down charts and other metrics are used to plan and track each Scrum or iteration.
I regularly mention in the training class that the SLIM is aptly named, because the full product suite supports the entire Software Life Cycle Management. The Agile methodology aligns with SLIM Suite, because it is also built upon the principle of disciplined discovery and delivery.
i Adapted from: Barry Boehm, Software Engineering Economics (Prentice-Hall, 1981), p.311.
Steve McConnell, Software Estimation, (Microsoft Press, 2006), p.3.