How four simple charts helped us get our focus back
A recent project reminded me once again how useful some simple big visible charts can be to help everyone on a project to work towards the same goal.
The project in question had been going on for a while but with the Christmas holidays coming up without us having completed any of the milestones, it became clear that while everyone was working hard, we weren’t actually shipping anything.
Looking into the causes, a few issues stood out:
- We had three major releases planned but much of our efforts had already shifted to release 2 and 3 before shipping release 1.
- We kept deploying minor releases to live, but we didn’t deliver the features we had set out to. The problem was the amount of “business as usual” work that was going on, with bug fixes and minor enhancements. Each item was important, of cause, but together they were eating our capacity.
- As the releases were getting delayed, we got more time to come up with improvements that were desirable to get done before we went live, leading to more work and causing further delay.
There were several underlying causes for all of this happening, which I won’t bore you with, but what was clear was that we had lost sight of the goal and that we didn’t have the focus we needed to ship our releases.
We needed to somehow make sure that everyone working on the project knew where we were going and how we were progressing. Intriguingly, we already had all this information but somewhat naïvely, it had all been hidden in Jira, where it was available for everyone but looked at by no one.
The solution turned out to be simple: go back to basics. Big visible charts to the rescue!
1. A release plan is only any good if it is visible
Due to the release plan being ‘hidden’ in Jira, the teams were effectively being served piecemeal items to work on, robbing them on their capability to self organise to deliver their work in the most effective way.
When we don’t give a team the bigger picture, it’s a bit rich to expect that they will be able to make the right decisions. For example, when there is overlap between two features, it might seem like a good idea to tackle them together in order to speed up the delivery. However, if one feature is needed much earlier than the other, this approach would cause unnecessary delay to that feature.
There are elaborate and visually appeasing charts available but in the interest of keeping it simple (both to read the chart and to maintain it), we settled on simply drawing a box for each epic in a grid to show which release it was needed for and which team was predicted to be working on it. A number in each box showed the number of points remaining for that epic and as an epic was completed, the box was filled in with green.
As the plan changed (as all good plans are able to do), this was quickly reflected through updating the chart.
Suddenly, everyone started talking about releases and what they could do to get them out. Success!
2. A velocity chart highlights if BAU is eating our efforts
During the first few sprints, we had managed to demonstrate that it is possible to get a lot of work. done without making much progress towards the goal if we kept working on a lot of BAU tasks.
As we were responsible for the maintenance of a live product, it was unavoidable that we would need to do some BAU. The challenge, however, was getting the balance right.
By starting to plot how much effort we spent on BAU vs delivering the project, with the story points spent on BAU plotted on the negative axis, it was easy to make this trade off visible. This helped us to get into the habit of questioning each item: “Is this really more important than the items in the upcoming release?”. On balance, not many items were.
3. The burn up shows when we’re predicting we will finish (and helps us finish when we said we would)
The release burn up is the bread and butter of charts in Scrum but we had sadly gotten out of the habit of using one. Instead, in a misdirected attempt at “the simplest thing that works”, we had just been relying on keeping the backlog up to date.
As we started using the burn up again, it was hard to see why we hadn’t done it sooner. I can’t think of any other way that shows as clearly how we’re progressing and when we’re predicting to be finished.
Through visually representing our deadline (a big music festival, which would be promoted using our product), we were able to keep adjusting our plan along the way to keep us on the right side of the deadline, deprioritising unnecessary requirements and finding cleverer approaches as needed.
Hello again, burn up. We’ve been missing you!
4. The burn down can help us make sure we do first things first
Arguably, it should be easy to make sure to focus on completing the items in one release ahead of the items in the next: just do it!
Once we had our eye on the ball, that’s mainly what we did, but simply visualising the remaining work for all the releases in a burn down chart gave us a control mechanism to ensure that the first release was progressing before the second and so on. And while burn downs are notoriously tricky to use for predicting when something will be finished (they make no distinction between a reduction in scope and progress towards the goal), it gave us some indication when each release was likely to be finished.
Nothing of this is new or groundbreaking. It’s all pretty basic stuff. It’s just that we had fallen out of the habit.
One trivial reason for this was our workspace lacking whiteboards. The solution proved simple: just sticky-tape A3 print outs of the charts on a large foam board and put it on top of a cupboard.
And it was so worth it. At the cost of just 10–15 minutes each sprint, the teams, product owner and stakeholders now all had the information they needed to be allowed to focus on first things first. Right in front of their eyes.
A useful reminder how helpful a few simple charts can be!