Demonstrating Progress in Agile
- Danielle Downs
- Mar 13, 2024
- 8 min read
One of the great myths about Agile project management is that it is difficult to track and forecast progress. This is a total fallacy.
Scrum in particular is very transparent and there is very little room to hide.
Daily Stand-ups
Let’s start with the daily stand-up.
Every day, each team member talks through the work they completed yesterday and what they plan to do today. If, at the next daily meeting, they haven’t achieved what they said they were going to do, they need to explain why and what is getting in their way.
This isn’t primarily intended to hold team members to account, but to enable other team members to help resolve potential impediments quickly, without waiting for them to be raised in a weekly (or even less frequent) “project update”, by which time they may have become a risk to or even an issue on the project.
As a side effect, it does however make it very difficult to conceal a “slow day” or an underperforming team member that might be in need of some additional support.
Using Burn-up & Burn-down Charts to Demonstrate Progress in Agile
Secondly, we have the Burn-up or Burn-down Chart.
These charts can also be updated daily, based on the team’s sprint goal, but this should not be necessary if the PO attends daily stand-ups and reviews each completed story, because they will be fully aware of the team’s progress and able to communicate it to any other interested parties. It is more common to update them with the team’s velocity (story points completed) at the end of each sprint.
So what are these two charts and what are the differences between them?
Burn-down chart
A burn-down chart can be used when the baseline scope of a project, MVP, iteration or feature set is known and the work has been estimated in story points.
The scope doesn’t however have to be fixed, as changes will be reflected in the scope line and the velocity projection updated accordingly. This has the useful effect of demonstrating the impact of scope changes on the timeline and reinforcing the need to take something of equal effort out, if the original timeline is to be maintained.
Even if not every story has yet been estimated, it may still be possible to estimate the total scope. This can be done using relative t-shirt sizes, where the team put the stories into “buckets” and each t-shirt size is assigned a number of story points; or, if the stories are sufficiently granular and the team is reasonably mature, it can be based on the number of stories multiplied by the team’s average points per story. If either of these methods are used, though, it must be remembered that the scope is only a high-level estimate and may go up as well as down (see below).
The burn-down line is then populated with the points completed each sprint, as the team “burns down” towards the goal.
After a minimum of 3 sprints, future progress can be projected based on the team’s average velocity to date, but this can be dangerous because it doesn't take account of peaks and troughs in the team’s capacity e.g. due to sickness or holiday. For this reason, many Scrum practitioners prefer to show “best” and “worst” case projections, based on the team’s 2nd worst and 2nd best sprint velocities, as well as the average. This is advisable until a team has been in place for at least a full year.
The point(s) where the line(s) meet the x-axis indicate the sprint when the required number of points will likely be achieved.
Burn-up chart
A burn-up chart should be used when the scope of a piece of work is unlimited, unknown or not yet estimated.
It can also be used to track progress towards multiple feature sets or iterations; in which case the scope is calculated cumulatively, with the points required to deliver each feature added to the last.
A burn-up chart shows what could be achieved over a given timeframe to aid prioritisation and release planning decisions. E.g. if a release date of X is required, the projections show the story points the team could likely achieve by that date.
The priorities can then be adjusted to ensure the most critical features and functionality are delivered first, even in the worst case scenario.
The difference in story points between the worst and best case projections can then be made up of ‘could have’ or ‘delighter’ features not considered critical for the minimum viable product (MVP). These items can be delivered as ‘bonus’ features if there's still time after the vital features have been developed.
If the team does run out of time, they will at least have had the best possible chance at delivering the most important features and can continue working on the lower priority items after the initial release.
Context is important
What is more important than how these charts are displayed is that they are used appropriately and taken in the right context.
Impact of Fluctuations in Team Capacity
A team’s velocity will fluctuate from sprint to sprint. Even when the team is stable and mature, there will be periods of holiday and sickness that will slow down progress. It is therefore important that the reasons for these variations are well understood and not taken in isolation as a sign that a project or feature is doomed to fail.
It is for this reason that I like to also include the team’s capacity on the burn-up chart, as it gives a better indication as to why their velocity may have been higher or lower in any given sprint. If, however, capacity wasn’t the reason and there is a downward trend for more than 1 or 2 sprints, it’s a clear sign that something else is going on that merits further investigation.
A story isn’t “Done” until it's Done
Something else non-practitioners may not know about Scrum is that the team cannot claim the points for a story until it is completed in its entirety. Even if 90% of the story is done at the end of the sprint and only QA is outstanding, the whole story has to be carried over — you can’t claim 90% of the estimated points! This means a team may appear to have had a “bad sprint”, where they only achieve a relatively low velocity, but have a “great sprint” the sprint after, if they are able to complete the work carried over from the previous sprint as well as the work planned in the new sprint.
Just because the burn-up / down line says the work will be completed a sprint “late” one week, it doesn’t necessarily mean the whole timeline is in jeopardy. Again, though, If the team is unable to catch up after 1 or 2 sprints, there could be a problem and the Product Owner may need to reduce or re-prioritise the scope in order to meet the desired timeline.
Estimates are estimates
Even if the true scope of the feature set doesn’t actually change, the scope line will move up and down as the team refine and estimate more stories.
If an estimation method was used as a proxy to estimate the scope, rather than the actual story points estimated by the team in refinement sessions, it is even more likely that the scope will change over time.
As per my other post, on just-in-time analysis (see link at the end of this post), the closer estimation is done to the work taking place, the more accurate the estimates.
In the example above, the estimates for the 1st feature (completed in the first 6 weeks after estimation) only increased by 5 points (10%), but the estimates for Feature 2 increased by 85 (57%). This was because the original high-level estimates were requested at the end of July and the team learned more about Feature 2 as they refined and developed more stories between then and November. This is why estimating a whole feature set up front can be misleading and of questionable value.
Increasing estimates aren’t always necessarily a cause for doom and gloom though. A team may decide to break a story down into smaller stories, to make it more granular and therefore easier to develop and test within a sprint. This often results in an increase in the overall scope because a single story might, for example, be no smaller than 3; thus splitting stories up can result in the sum of the parts being greater than the whole.
In Scrum, though, this doesn’t matter because, if more granular stories mean the team burns through points quicker than previously, their velocity will increase to make up the difference. It just results in some “inflation” as you might expect with any currency. This is why it is difficult to compare velocities between teams, because it depends on the granularity of their backlog and the relative estimation that they use, which will gradually diverge between two teams over time.
Conversely, as a team becomes more familiar with a feature, they may find they can merge stories together. For example, displaying the same component on one page may be very similar to displaying it on multiple pages, so they might decide to build it all on the pages at once. Estimates do go up as well as down and they are more likely to increase at the start of a project or feature and decrease towards its completion. This is illustrated in the graph below, which shows the team’s revisions to the original estimates for the stories required to build “Feature 2” from the example above. Initially, the estimates only appeared to increase but, as the team gained more experience, they also began to decrease.
Undiscovered complexity
Sometimes, despite everyone’s best efforts, a team will encounter unexpected complexity or an impediment that reduces velocity and causes estimates to increase. It is these events that have to be most closely monitored to know when to intervene.
The team could be lacking expertise in a certain area, so it may be necessary to up-skill or bring in additional resource.
They could be using unfamiliar technology, requiring a steep learning curve. In this case, a decision has to be made as to whether the benefit of using the new technology outweighs the additional time and effort involved in using it. If so, the timeline may need to be adjusted, or the scope reprioritised to ensure delivery of the most critical features.
If a particular feature is taking a disproportionate amount of time (i.e. more than 1 sprint) to complete, the Product Owner may want to consider a compromise between their ideal solution and something satisfactory but less complex.
Why it works
Ultimately, any potential impediment can more easily be mitigated the earlier it is discovered. One of the major benefits of Agile and Scrum is that progress is completely transparent and can be tracked on a daily basis. Any likely disruption will be immediately apparent to both the team and the Product Owner, so remedial action can be taken.
Burn-up/down charts can indicate trends but they require the knowledge and context, shared between the team and Product Owner, to fully understand the cause of any reduction in velocity and if it is likely time can be made up in subsequent sprints.
Conclusion
The Agile Manifesto encapsulates it quite succinctly:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
While Agile may not have the detailed documentation of traditional waterfall project methodologies, project initiation documents, Gantt charts, risk registers and issue logs are no substitute for a team working together to solve a problem.
The role of the Product Owner in Agile is to be in daily contact with the development team and bridge the gap between them and commercial stakeholders, reducing the need for additional documentation and weekly or monthly project status reports. If a stakeholder wants to know how a team is progressing, they just ask the Product Owner.
Extensive documentation may give the illusion of control and complete transparency but the cadence of waterfall project governance is such that, by the time a problem is discovered, it may already be too late to mitigate. In addition, the overhead of completing such documentation takes effort and resources away from delivering the product and is unlikely to realistically make it happen any quicker.
Comments