Businesses need schedule certainty and stability to be effective. Unfortunately, Agile processes are not always well equipped to deliver schedule certainty. Providing support for things like long-term feature planning, scope management, or creating and sustaining a product roadmap are not a natural fit for Agile. In other words, Agile is not, by its nature, a “deterministic” methodology. Therefore, it has few provisions for providing predictable costs and schedules to the business.
So how can we add the much-needed deterministic capabilities to Agile?
The key to adding deterministic capabilities to Agile is to add a lightweight estimation process that can forecast when work will be completed. This article will discuss how to add an effective estimation process to Agile without sacrificing the existing benefits of Agile.
Deterministic Agile (DA) Approach
Deterministic approaches like Waterfall historically were intended to provide stability, scope, and schedule controls over development projects. These controls provided a degree of certainty with regard to when new product capabilities would be released to the business. On paper, Waterfall was a very elegant solution. It had many benefits, especially when the cost of introducing change into a business was high. In practice, Waterfall’s deterministic approach often placed a strain on teams by pushing for scheduling certainty without allowing scope or capacity to be adjusted.
For this and other reasons, thought leaders decided to revisit some of the founding principles of Waterfall development. Many decided to turn the Waterfall development model on its head for a new, more non-deterministic or capacity-based approach. This approach is what we know today as Agile.
Compared to Waterfall, Agile touts a number of benefits to businesses including improved quality, increased customer satisfaction, and reduced risk. However, the rush to embrace those benefits have come with a cost. The primary cost is that Agile, unlike Waterfall, is a non-deterministic approach. Agile teams are not well equipped to provide long-term planning, scope management, or creating and sustaining a product roadmap.
Naturally, the idea of drawing from the best of Waterfall and Agile has gained prominence. But mixing deterministic and non-deterministic approaches can be challenging. It can feel like cleaning an oily frying pan with just water: No matter how much water we use, we still can't get the pan clean. The good news is that there is a simple solution to this problem. In the case of oil and water, the solution is to add another ingredient: soap. In the case of deterministic and non-deterministic approaches, the solution is to add a lightweight estimation process to forecast (but not guarantee) when work will be done.
The following steps will explain how to add needed estimation capabilities to your Agile development project, and obtain a Deterministic Agile (DA) outcome.
Step 1. Estimate the Scope
In a pure Agile model, teams are encouraged to refrain from estimating more than 2-3 sprints down the road. This short-term approach is the Agile oil, while the desire for a longer-term scope estimation is the deterministic water.
To effectively combine these approaches, teams will need to invest more project time up front (2-4 sprints) before development sprints begin.
The upfront time will be used to evaluate the right features to build over the course of the project. It's also used to estimate the relative size of those features to establish scope. It should be noted that this up-front investment is NOT traditional “requirements gathering” or detailed story estimation. Rather, this lean Discovery period is for building a shared understanding of the goals and features for the project. It's also to create a lean roadmap that can be updated and evolved over time.
To summarize and visualize a shared understanding and to estimate the scope, the team should perform a user story mapping session with the project stakeholders and end users (See Jeff Patton's book for more details).
Once the story mapping is complete, the team needs only do a relative sizing activity of the “backbone” features (i.e., key features related to the target release) and some simple math to estimate the initial scope of a project.
DA scope calculation:
- Identify the backbone features needed for a given release.
- Relative size all of the features. Assign each feature a size from Extra Small (XS) to Extra Large (XL). Associate each with a numeric scale. For example, XS=1, S=3, M=5, L=8, XL=13, XXL=21.
- Evaluate the story point size of at least 1 XS feature. For example, 1 XS feature = 13 story points.
- Number-crunch the story point size for the other feature sizes. Do so by multiplying each feature size against the XS story size. For example, if XS=13pts then S=39pts, M=65pts, L=104pts, XL=169pts, XXL=273pts.
- Estimate scope by multiplying each feature against its story point size and summing them together. For example, if the project includes 1 feature of each estimated size then the Scope=663 story points.
Note that the initial scope will not be very accurate. However, the scope should be continually updated over the course of the project to improve the accuracy of the scope estimate.
Step 2. Achieve a Predictable Velocity
Now that we have covered a lean method for establishing project scope in step 1, we need to explore how fast the team can complete that scope over time. Fortunately there are Agile metrics like velocity that can be used to estimate the team's expected output.
In order for velocity to be an effective metric for a team, the team must have a stable steady-state velocity. That steady-state velocity can lead to predictable results sprint-over-sprint. In other words, it is not enough for the team to commit and complete 80 points of work during one sprint, then commit and complete 20 points of work the next sprint. The team must consistently commit and complete the same amount of work sprint-over-sprint. Then future sprints are a reflection of the previous sprint.
Once the team has a stable steady-state velocity, longer-term impacts such as PTO for team members, holidays, and other project impacts should be mapped out over the course of the project to provide a more accurate estimate of how much work the team can complete over time.
Step 3. Forecast the Completion Date
The last step of a DA approach is to do the math and forecast the results. Compare how much work the team can get done (see step 2) against the projects calculated scope (see step 1). The intersection of these values will determine the forecasted completion date. (See “burnup” chart below)
- If the team is able to complete more than the defined scope by a defined target date, then the team is considered to be on time with a high degree of certainty that they will make the date.
- If the team completes less than the defined scope by the defined target date, then the team is considered to be at risk for making the date.
Putting Deterministic Agile into Practice
It is important to remember that a DA approach is designed to forecast how much work can be completed by a given date. But it does not absolutely guarantee completion of all scoped work by that date. By taking this approach, teams are able to engage in crucial conversations with the business so that scope and capacity can be understood and adjusted early in the project. By working with the business to balance capacity, scope, and schedules holistically within an Agile process, teams can still deliver something of agreed-upon value by a defined date.
