In October 2012, we released our first downloadable template to help forecast and chart release progress. Since that time, we’ve helped many organizations transition to Agile and found some recurring needs that have driven the creation of the Advanced Release Charting template:
- Set expectations about deadlines and report to stakeholders. Will the desired scope be done by the deadline? Is the project still on track? How can we ensure successful delivery? What should we tell our customers? What work has been identified but not estimated (i.e. not reflected in the forecast)?
- Prioritizing the backlog items within large projects. All too often projects are seen as all or nothing when in fact there is room for discussion about the importance and impact differences. Are you working on the right things? Are they all valuable? Is the investment proportional to the value?
- Backlog items are often too small to report against. Customers and stakeholders are more interested in understanding which high-level features are at risk or how they are progressing.
- Product owners need to a better way to look at their backlog and understand which items are least likely to make it.
In the first installment of this two part blog series, we will focus on high-level release planning and tracking. Understanding how to communicate at this level is the first step in managing expectation with stakeholders and customers.
Release Forecasting (High Level)
Each release has a vision, objectives, and pressure to deliver against commitments. These commitments come in the form of scope, schedule, or both. In Agile, we value frequent delivery which allows us to regularly communicate progress and manage expectations with customers and stakeholders.
Each release has a set of constraints and we encourage our customers to define a project trade off matrix to identify which constraints are fixed, chosen, and adjustable. Once these are understood we can pick the right model to report progress, such as fixed date or fixed scope burn charts.
Fixed Date Release
Fixed date releases combine the pressure to deliver with the flexibility to negotiate scope. When a release date is fixed progress comes in the form of completed scope and expectations are set by forecasting how much of the remaining scope is likely to be delivered. We provide a Forecasted Release Burnup chart to review the health of the project, at a glance.
Let’s take a closer look at an example.
In the burnup chart above, the release has a fixed schedule of 10 two week sprints, or 20 weeks. The project started on February 25th with a planned scope of 70 units of effort, often measured as story points in Agile organizations. The team responsible for the release has already completed three sprints and has begun their fourth. What can we tell by looking at the chart?
First, it’s clear by looking at the planned scope line that the amount of required effort for the release is increasing. What it doesn’t tell you is why. Many people might quickly conclude that the product owner has accepted additional feature requests from their customer and the team is being asked to deliver even more work. This might be the case, but there are other possibilities. In Agile, we replace big up front planning with just enough planning at the start and recurring planning based on continuous feedback and learning about what’s needed to deliver the right outcome. With this in mind, the increase in planned scope could reflect revised estimates provided by the team after they gained a better understanding of the work.
Next, we turn our attention to the actual and forecasted output. In Agile, we recognize that we cannot perfectly predict what or how much will be delivered in a fixed date release. Instead, we communicate a range of output based on risk multipliers or optimistic and pessimistic trend lines.
In our sample burnup chart, you can see that we are communicating that the team will deliver somewhere between 52 and 78 unit or points of effort by the end of Sprint 10. You’ll also notice that there is a gap between the planned scope and the scope that we forecast with 10% confidence. The gap against the forecast that has 90% confidence is even wider. So what can we do?
Before we consider our options, let’s examine the data on the chart further. Notice that as sprints are completed our output reflects actuals and only future output is forecast. In this case, you’ll notice the team has completed about 27 points after 3 sprints, or an average velocity of 9 points each sprint.
Now let’s look at some possible options to explore by themselves or in combination:
- The team is outperforming our expectations, with a velocity of 9 points instead of 7 points, so let’s adjust our expectations based on their performance. If we increase their velocity to 9 points, then the forecasted output tilts upward and we gain confidence in our ability to deliver the planned scope.
- We recognize that the team has some upcoming vacation and that the original velocity of 7 points already takes these types of outages into account. Consequently, we leave the velocity and look to address the mismatch in scope another way.
- We cut scope by agreeing on the least valuable features. This may even involve the compromise of releasing some of the higher value features earlier to gain an earlier return on investment.
- We identify another team with sufficient knowledge of the product to deliver a subset of the features while keeping the existing team focused on the remainder of the release backlog.
- Perhaps new information drives us to understand that the release date can be pushed out after all and we extended the release by one or two sprints to deliver the desired scope. While this goes against the notion of having a fixed date release, it acknowledges that circumstances can change which might alter constraints.
The data provided by the burnup chart allows these discussions to occur to determine the best course of action. Consequently, the chart is updated at least once per sprint and communicated to stakeholders to manage expectations.
Fixed Scope Release
With an understanding of how to read a burnup chart, it’s easy to flip the constraint to a fixed scope and range of dates. For this we use a burndown chart.
Burndown charts allow us to forecast potential dates for the release. In the example above, we need a further date horizon to identify the range of actual dates. So far we can only tell that it will take the team longer than 10 sprints, and probably around 12 to 15 sprints, to complete the planned scope. Even a fixed scope release, will undergo some amount of discovery by the team leading to revised estimates. In the case those estimates are larger, the remaining scope will be a combination of the actual work completed and the increase in effort.
Undefined Effort
The burnup and burndown charts reflect the work that is known and estimated by the team. As the project progresses additional work will be discovered and the team will continue to provide estimates. Sometimes those estimates lag behind the identification of new work. The more unestimated work the less information people have about the health of the project.
The simple pie chart above shows that 20% of the user stories or requirements in the release backlog have not been estimated. How does this information change your perception of the project? Should you reserve some of the team’s capacity in the next sprint to estimate the remaining work? Would it be better to find places to cut scope now realizing that the estimated scope is already at risk?
Using Our Template
Our template is simple and easy to use and allows you to use a burnup chart, burndown chart, or both by updating just a few fields each sprint on our ‘Data’ worksheet. The charts are automatically updated to reflect the changes without any need to understand the formulas involved. We also allow you to define your cone of uncertainty (i.e. range of outcomes) using either industry established risk multipliers against velocity or establishing your own confidence intervals based on past or expected performance.
The pie chart of estimated and unestimated user stories is driven by the ‘Product Backlog’ worksheet which is a detailed view of the backlog populated from your Agile Project Management Software (e.g. TFS, Jira, Rally, VersionOne, etc.).
Advanced Release Charting Template – Part 2