Agility and Predictability
“Some businesses value agility, but many businesses value predictability more than they value the ability to change direction quickly. For those businesses, becoming more Agile is a second level consideration; the first level consideration is how to become more predictable. … [While] Agile does allow you to change directions more easily […it] doesn’t require you to change directions and it certainly does expect you to have a direction. [So] how does Agile give you a predictable schedule? By giving you early, frequent, and fine-grained feedback and allowing you to steer the project to that schedule."
We’ve been selling the benefits of Agile for some time now – great ROI with incremental return, speed to market with greater adaptability, greater visibility, and lower cost. However, what a large enterprise also needs is predictability. This need is often expressed in requests for measures and metrics.
So, how is Agile more predictable than traditional Waterfall?
- First, the Agile Project-Release Plan is based on the empirical velocity of the Agile team. The initial average velocity of an Agile team is based on the actual value (in story points) completed during the first three sprints. In other words, the initial Agile Release Plan is based on the actual performance of the team performing the work.
- With the empirical average velocity and the total Agile Project effort (which is determined by grooming the backlog and is also in story points and established by the end of the first three sprints) you can determine:
- The Agile Release Plan can be refined at the end of every sprint based on the actual performance of the team.
- Finally, Agile delivers fully tested stories with every sprint. In practice, this should include automated regression testing so you know it continues to work. The traditional approach leaves testing in general and regression testing in particular to the very end when there’s little time to fix problems that are discovered. This late discovery leads to the lack of predictability in a traditional approach.
Agile Release Planning IS Project Planning
The traditional approach is to create a serial, phased project plan for review at a Planning and Requirements Gate. While the project plan will provide a prediction of the delivery date, in practice the delivery date is often known even before the start of planning as many projects are started with all three sides of the iron triangle – scope, schedule, and cost - already constrained.
For the Agile projects, a Release Plan is created comprised of the sprints required to complete the project and is based on the total release effort estimated in the project backlog and the team velocity established during the first three sprints. Roughly, if you divide the total release effort by the team velocity you will have the number of sprints necessary to complete the project.
While an Agile Release plan is initially based on estimates and equivalent to a traditional serial, phased project plan, it is unlike a traditional project plan in that it can be refined at the end of every sprint based on the actual performance of the team. If an Agile Release plan cannot meet the required delivery date, an Agile PM has the same options as a traditional PM:
- Add resources (and cost) to increase team velocity or
- Reduce scope (the total project/release effort)
However, the Agile PM also can manage scope at a more fine-grained level whereas the traditional PM often cannot. (This is referred to as grooming the backlog.) In Agile, teams do the most important things first. Instead of leaving whole features to the end, “nice to have” refinements can be left to the end.
Scope Management
At the end of every sprint, you know exactly where the project stands and the effort required to complete the project on schedule.
A Project-Release Burn Up chart displays scope (expressed in story points) over time (expressed in sprints). For every sprint you have a complete view of the project and snapshot of the current project status information:
- Total Release Effort = size of the project/release backlog
- Avg Earn Needed = the cumulative work (in story points) needed to be completed to stay on schedule
- Forecasted Earn = the cumulative work (in story points) forecasted to be completed
- Actual Earn = the cumulative work (in story points) completed
- Forecast (velocity) = the work (in story points) planned to be completed in the sprint
- Actual Velocity = the work (in story points) completed in the sprint
Project Scope Status Measures and Metrics
- Actual Earn vs. Forecasted Earn vs. Average Earn Needed = 369 vs. 578 vs. 438 story points completed
By Sprint 10, the project has completed 369 story points which is both less than the forecast of 578 story points and less than what is needed to complete the project on time 438 story points. While the project is behind plan, it is recoverable (see below).
By Sprint 10, the project has completed 56% of its planned scope.
Project Scope Performance Measures and Metrics
- Actual Velocity vs. Forecast Velocity = 11 vs. 212 story points per sprint
The team may have encountered a serious issue to only complete 11 out of 212 planned story points. It may also be possible that the team is not reporting their work. More than likely, this snapshot was taken before the end of the sprint (perhaps in the first few days) so the actual velocity (to date) for the release is acceptable and no action is necessary if the individual Sprint burn down chart does not indicate an issue.
At the end of Sprint 10, the project needs to complete 96 story points per sprint to complete the project on time. This is achievable because the maximum velocity to date was 162 story points in Sprint 08. So, while the project is behind plan, it is recoverable because the team is able to deliver a maximum of 162 story points in a Sprint and only needs to deliver 96 story points for each remaining sprint.
This metric is a measure of the value delivered by the team. If this is the end of sprint 10, only 5% of the planned stories have been accepted for the sprint. It may also be possible that the team is not reporting their work. More than likely, this snapshot was taken before the end of the sprint (perhaps in the first few days) so the actual velocity (to date) for the release is acceptable and no action is necessary if the individual Sprint burn down chart does not indicate an issue.
Schedule Management
The Release Burn Up Chart can also provide you information on your project schedule performance. Here, the information about the schedule is in the relationships of the lines.
Project Schedule Performance Measures and Metrics
- The Avg Earn Needed line represents the work progress needed over time to develop the entire project backlog (aka the Total Release Effort).
- Any line ABOVE the Avg Earn Needed line shows more work (in story points) than planned and is therefore AHEAD of schedule.
- Any line BELOW the Avg Earn Needed line shows less work than planned and is therefore BEHIND schedule.
In the chart above, the project is forecast to be ahead of schedule throughout the life of the project. However, in Sprint 10, the Actual Earn line dips below the Avg Earn Needed line showing that
the project has fallen behind schedule. It may also be possible that the team is not reporting their work. More than likely, this snapshot was taken before the end of the sprint (perhaps in the first few days) so the Actual Earn is acceptable and no action is necessary if the individual Sprint burn down chart does not indicate an issue.
Time Lines vs. Burn Charts
It's easy enough to convert the project status information from a release burn up chart to something more familiar like a project timeline. This may be necessary when communicating project status to stakeholders who are used to receiving project information in the form of a timeline rather than a burn up chart.
But when you collapse the two-dimensional burn chart into a one-dimensional timeline you lose valuable information related to the scope and schedule performance of the project. One of the first questions a stakeholder might ask when seeing the timeline above would be "Is it recoverable?" or "Will you make your delivery date?". While the PM might answer yes, there is no facts or data in the timeline to support that response. With a burn chart, you could point to the fact that the velocity to complete is 96 story points and the team has delivered a maximum of 162 story points in the past (Sprint 08). So if you have to report status using time lines, be sure to have a release burn up chart as supporting documentation.
Cost Management
Burn up charts can also be used for cost management and budget performance. You can create a financial burn chart that displays cost/budget (expressed in dollars) over time (expressed in months).
- Revised Plan = Total budget
- Forecast = Cumulative planned spending
- Actuals = Cumulative budget spent
- Monthly Actuals = Budget spent per month
- Monthly L/E = Latest estimate or forecast per month
Note: The time period of the financial burn up chart is monthly. The time period for release burn up charts is sprints (which are generally two to three weeks long).
Project Budget Status Measures and Metrics
By July, the project has spent 55% of its planned budget. As shown in the next section, this is slightly under budget.
Project Budget Performance Measures and Metrics
The Forecast line represents the planned spending over time to consume the Total Budget (aka the Revised Plan).
- An Actuals line ABOVE the Forecast line shows more budget spent than planned and is therefore OVER budget.
- An Actuals line BELOW the Forecast line shows less budget spent than planned and is therefore UNDER budget.
Project Management FAQs
Traditional project management starts with the question, "What do you want me to build?" which is quickly followed by "How much will it cost?" and "How long will it take?" In other words, the project starts with scope and you estimate cost and time. This approach can give the illusion of certainty. I asked for what I wanted and got a cost estimate and a timeline. The problem is that we don't know enough about what we want to provide good estimates. And even if we knew what we wanted, we don't have perfect knowledge of how we would build it or how long it would take.
This relationship of scope, schedule, and cost is captured in the Iron Triangle which models the constraints of project management:
- Scope – what must be built
- Schedule – when it must be finished
- Resources – who builds it, how much it must cost.
In traditional project management, the scope is fixed and the quality, schedule, and cost are variable. The rule is “Good, Fast, or Cheap – Pick any Two”.
- Image from The Project Triangle Turned Upside Down
Agile flips the triangle upside down and asks the questions, "How much time do we have?" and "How much do we have to spend?" After the time and cost are established, the scope is varied to deliver within those constraints. Think of this In terms of product development: We have to be in a market at a certain time and we only have this team of people to do the work. (Our time and resources are fixed.) What can we build in that amount of time for that amount of money that will yield the most value for our stakeholders? (Our scope is variable.)
When will the project run out of money?
As part of Release Planning, you determine the total budget required:
If the available budget is less than the total budget required, then there isn’t enough money for the entire project. If your available budget is less than the total budget required, you can determine how many sprints are funded by the available budget:
How much of the project can I complete with the available budget?
You can also determine how many story points you can complete with the available budget:
The Bottom Line
Agile is not only adaptable, it’s also very predictable. And burn up charts give you most of the measures and metrics you need to manage the iron triangle of project management: scope, schedule, and cost.
