Posts Tagged Burndown
When agile is working at scale, with multiple teams, there is usually a need to see progress through the work at different “zoom-levels”.
Most familiar is the story zoom-level: How are the stories progressing? Are they blocked? Why? How is the iteration progressing? Team boards, and team level hacks, help us to see these things change, and to understand how to improve.
At a higher zoom-level, the visibility needed is: How are multiple teams progressing through the larger pieces of work (we’ll call them features) which the stories are part of. So what we need to see is: When are they likely to finish this feature? What’s at risk? What’s blocking the team? Does the team need help?
This level of information is often represented on a program wall, which is a bit like a “zoomed-out” version of a team wall, showing the backlog of features to be delivered, cycle time across the whole program, and so on.
Here’s an example of a program wall. Each team is represented by a horizontal row and the columns are the iterations in which the teams expect each feature to finish.
The detail of how these features are tracking is found on the individual teams walls. But one team found a way to clearly summarise their progress on this wall too. They decided to stick burnups onto the front of each feature card. (A burnup is one of the most eloquent of board hacks as it provides a single view of scope and velocity, as both change).
You can see it a little better below:
So now, when you’re standing at the feature wall you can see the burnup for that feature, right on the front of the feature card without having to go and find the team wall. In this example, the feature is in the Iteration 12 column, but the burnup tells me it’s more likely to finish in the 14th iteration unless something changes – I smell risk! You can get a very rich sense of what’s going on, at a glance.
Spotted: Telstra Contact Solutions
Here’s a tool for teams doing commitment – based planning.
On this chart there is confidence slider per day of the iteration. Team members individually mark their confidence that the team’s commitment will be reached on the chart after standup, with a line. On the left of the scale is “Very scared that we will not achieve everything we have committed to this iteration”. On the other: “Very confident that we will deliver everything that we have committed to by the end of this iteration.”
This one makes an excellent conversation starter. “Why do you feel that we will / wont make the goal?” The answers may well reveal risks which may have remained hidden. Different teams will display different patterns. For some, they become more confident as the iteration progresses. For others, you will see the cloud of marks moving back to the left.
Below you can see the clusters of lines, and you can see outliers: skeptics, or optimists. Graeme, the Iteration Manager, says: “For stakeholders, or other interested people, they can see how the team feels about a commitment.” That’s hard to argue with. “I like it better than a burndown chart.”
It certainly looks like a better form of reporting than the standard RAG Sheet.
Look below: this iteration, the team have divided on the fourth day in, with at least three team members strongly convinced the goal is out of reach. What happened on Wednesday? A great conversation starter.
Spotted: Telstra Contact Solutions CCRI team, Graeme Robb.
Team says: “The days are decreasing at exactly one per day, but the feature cards definitely aren’t!”
We’ve seen agile burn-down charts many times. But here’s a different approach. This team runs a lean/kanban board, and they don’t estimate in points, so they decided not to use the traditional burn-down chart. Sometimes, there are immovable deadlines and in this case an author was going on the road to research a destination. Tickets were booked long ago and there was no possibility of delaying the release.
As the release date approached the team simply kept track of the number of feature cards versus the number of days left. This was a nice simple metric which stared them in the face every day, and gave urgency to the task of ruthlessly cutting scope to meet the date. The days always decrease of course, but the card count can increase as additional stories are uncovered. Sometimes product owners can be reluctant to cut scope, but this made it painfully obvious that it was necessary in order to meet the release date. When the number of remaining cards fell below the number of remaining days the back of the beast was finally broken.
Spotted: LPOS Team