Use of the agile principles (the second pattern) in program estimation is gaining broader adoption every day with the increasing maturity and confidence of enterprise IT organizations about their agile capabilities. This makes sense as the scope elaboration sessions with the capability owners, product managers, product owners, and agile team leaders produce best insights about what the program should do and how. Multipliers provide rapid rough estimates for enabling capabilities and visibility into the efficiency of their consumption.
Figure 2 – Agile Program Cost, Plan vs. Actual Comparison
As illustrated in Figure 2, the total planned investment for an agile program consists of a calculated estimate for the Agile, Core component and derived estimates for the Agile, Noncore and the Enabling components. What happens to these investment components during program execution is pretty astonishing. Let’s review them one by one:
Agile, Core - During program execution, epics are divided into new features, features into stories, stories into scenarios, etc. Agile teams continuously elaborate and size these new scope items using story points or similar methods. Once approved by product owners, scope items are prioritized and added to an appropriate product backlog. At this point, agile teams implicitly re-estimate the Agile, Core investment component for epics that were already funded by capability owners.
Due to a complex matrix relationship among capabilities, projects, products and agile teams, the re-estimates don’t necessarily make their way back to capability owners for reconsideration of their investment priorities and options, causing the capability level commitments being constantly redefined without a proper governance. The Agile, Core investment component estimate can easily double during the program execution phase, if the feedback loop from agile teams to capability owners is not functioning properly.
Separately, agile teams may not achieve their velocity targets that were assumed during the planning cycle. This may be due to challenges within teams, or factors not controlled by them. For example, environments may not be available or high-priority stories may be added to team backlogs unexpectedly mid-sprint. Clearly, these conditions should have been addressed at the program level before they hit the team; otherwise, it may not be possible to keep agile teams accountable for their velocity. Sustained velocity gaps are not factored into the original estimates, and they add up to 40% variance to the Agile, Core investment component.
Agile, NonCore -Typically, agile teams spend 10% to 15% of their time on noncore activities. However, this figure can increase to 30% to 40% if the program operating model is not adequately streamlined or automated.
When the Agile, Core effort increases due to re-estimates or velocity gaps, agile teams can’t simply hire new resources, since the team capacity is fixed. The new demand can either be addressed through a demand rationalization or by adding new sprint cycles to releases. Demand rationalization requires empowered product managers and highly effective feedback loops to the capability owners. Otherwise, new sprint cycles will be inevitable. Additional cycles cause the Agile, Noncore effort of the program grow proportionally to increases in the Agile, Core effort.
Sign up for Computerworld eNewsletters.