TL;DR: Use Burn-Down Charts to Discover Scrum Anti-Patterns
A burn-down chart tracks the progress of a team toward a goal by visualizing the remaining work in comparison to the available time. So far, so good. More interesting than reporting a status, however, is the fact that burn-down charts also visualize scrum anti-patterns of a team or its organization.
Learn more about discovering these anti-patterns that can range from systemic issues like queues outside a team’s sphere of influence and other organizational debt to a team’s fluency in agile practices.
Scrum Anti-Patterns Visualized by Burn-Down Charts
Burn-down charts have become popular to provide team members as well as stakeholders with an easy to understand status whether a sprint goal will be accomplished. (Critics of the burn-down chart may note, though, that a scrum team should have a gut feeling anyway whether the sprint goal is achievable.)
Hence, this post is focusing on another useful aspect of burn-down charts: they are equally well suited to provide additional insights into all kind of impediments, both at a team level and at an organizational level.
The following graphs visualize four of the typical anti-patterns that can be easily detected with burn-down charts:
1. Late Acceptance
The product owner accepts or rejects tasks only late in the sprint:
This behavior may be rooted in various issues, for example:
- The absent product owner: The product owner is rarely available for the team to clarify matters and accept work. This is creating an artificial queue that has a diminishing effect on the team’s ability to deliver value by delaying the necessary clarification of tasks or the shipment of tasks themselves. (Note: LeSS susceptible for this effect when the product owner when not willing to delegate responsibility.)
- The proxy product owner: The team is working in a remote setup and the product owner is not onsite with the rest of the team. (Note: A proxy product owner is usually not a solution as he or she will just increase the time for feedback and add to the communication problems.)
- Consequences: There will likely be a spill-over to the next sprint as the feedback loop does not provide enough time to fix issues during the sprint. The team will probably not meet the sprint goal. If this not an isolated incident but a persistent pattern, action needs to be taken.
2. Slow Progress
In this case, the graph is located above the line of the expected progress for the complete sprint length:
There are several reasons why this might be the case:
Recommended for You
Webcast, February 20th: The 7 NEW Steps to PPC Domination in 2018
- The ambitious team: The sprint goal is too ambitious and the team realizes only during the sprint that it will not deliver the sprint goal. (Note: It is okay to aim high and fail, however, it should not be the regular pattern as it is negatively influencing the trust of the organization in the team.)
- The submissive team: The sprint goal is too ambitious from an engineering perspective. However, instead of speaking up, the team tries to make it happen thus failing at the end of the sprint.
- Capacity issues: The capacity of the team changes after the sprint starts, for example, team members get sick, or they give notice and leave the team. (Note: Admittedly, this is hardly plannable anyway.)
- Change of priorities: The team needs to address a critical issue—probably a bug—which leaves less capacity to accomplish the original sprint goal. (Note: Depending on the magnitude of the disturbance it might be useful to consider canceling the spirit. At least, the team needs to reduce original sprint scope—which may require a mid-sprint re-planning to determine whether a reduced sprint backlog will still deliver the original sprint goal.)
- Outside dependencies: The team faces dependencies outside its sphere of influence not foreseeable during sprint planning. (Note: A classic systemic dysfunction.)
3. Scope Increase
The scope of work increases over the course of the sprint:
Most of the time, this pattern can be attributed to inadequate preparation:
- Refinement failure: The scrum team fails to refine tasks accurately only to discover that the effort to create a valuable product increment is higher than originally expected. (Note: If this happens multiple time during the sprint then the team accepted stories into the sprint the team has not fully understood. This points at serious issues with the product backlog refinement process or the collaboration with the product owner in general.)
- Dynamic sprint backlog: Urgent tasks are pressed or find their way into the sprint without compensation. (Note: Depending on the magnitude of the tasks, canceling the current sprint and focusing on the apparently more valuable new issues might be the better alternative. Unless, of course, those new issues are hacking the scrum process of sprint planning. There are several examples of this behavior: A manager pulls strings to get his or her task into a sprint or tasks are disguised as critical bugs that need to be fixed immediately.)
4. Early Finish
The team accomplishes the sprint goal way earlier than expected:
Of course, an early finish is the anti-anti-pattern if the team figured out how to deliver a task with much less effort than expected. Or the sprint goal could be achieved with fewer tasks that planned.
However, the positive news might also hint at some problems. Again, the reasons for this phenomenon are multi-faceted. My two top-candidates are:
- The overly cautious team: The team probably overestimated the effort to be on the safe side with its prediction. (Note: This could indicate that the management tracks, for example, velocity as an important metric for the contribution of the team members despite its limited usefulness. Or the organization is output oriented and does not accept ‘failure’ as an option. In these cases, the organization is setting the wrong incentives. See also the Hawthorne effect.)
- A hack for slack time: The team included buffer time to be able to address technical debt, its need for pairing or other issues that do not regularly receive attention and hence managed to finish early. (Note: This might indicate that the current allocation of resources is neglecting the long-term health of the team as well as the code base. Also, watch out for the feature factory syndrome where team utilization and output matter more than the long-term outcome.)
Conclusion—Use Burn-Down Charts to Discover Scrum Anti-Patterns
It is a good idea to use burn-down chart patterns for the next retrospective as they easily identify team problems or systemic dysfunctions. And utilizing burn-down charts in that capacity does not even require switching to story points per se—equally sized stories can just be counted to create a dimension for the y-axis.
Enhancing burn-down charts with additional data, for example, context and occurrences, as well as lead time and cycle time values, will increase the benefit of burn-down charts even more.
Speaking of which: At the team level, I would suggest creating a rotating scheme of team members to update the burn-down chart daily. It is a team exercise and not the job of the scrum master.
Lastly, no matter what purpose you are using burn-down charts for, avoid falling into a common trap: Start counting subtasks. This accounting will quickly lead you on the track of abandoning your definition of done. Instead, you will start marking tasks as 90 % complete. Welcome to cargo cult agile—how would that differ from the waterfall approach?
What scrum anti-patterns that burn-down charts can reveal are missing? Please share with us in the comments.