In my last post I discussed why we use burn-up charts instead of burn-down, the basic premise being that by separating scope from delivery makes (in my opinion) the impact scope change has on project delivery much clearer: as well as a useful internal progress and planning tool, they enable me to work with the client to make decisions about how we keep a project on track depending on project priorities. In this post I’ll use a fictional project to demonstrate how I might do this.
Here’s the basic premise for a fictional project:
- We’ve got a product backlog containing 88 points
- Based on data from previous projects using similar technology I know it will take roughly 5 sprints to gradually build to an average top velocity of 8
- Given the above I can say with a decent level of confidence we need to allocate 13 sprints
This is what our burn-up chart looks like before we start:
I’ll discuss the project timelines with the client and explain the burn-up chart. The client is keen to get moving so they book in their PR and marketing team to work towards a launch date not soon after the final sprint (meaning moving the launch date would be difficult and costly).
Before we see how it pans out, let’s get this straight; we know this ISN’T going to happen:
Forward to Sprint 5 and things have gone as expected (nice) and I’m pleased with progress, yes, we’re behind the trajectory line but a slow start was anticipated and we’ve hit full velocity meaning I’d expect to see us closing the gap in the next few sprints.
What happens next? Our client QA’s the work we deployed in the latest sprint and puts it in front of a small selection of real customers to get feedback. They come back to us with this: ‘We’ve had a really productive user testing session and I’ve thought of a really good way of improving the engagement level in year one. Can we do x/y/z?’ So we explore the new opportunity and on paper it looks positive, we add user stories to the backlog, 12 points in total. Now we’re looking at this:
At this stage I talk to the client and we go through the options. It looks like we won’t complete all the points by the end of sprint 13 even if we exceed full velocity from time to time. As we’re relatively early in the project I’d advise we see how it pans out for a few sprints before we do anything. Between us we agree (do this in writing) to review in 2 more sprints.
We complete 3 more sprints and we’re maintaining full velocity but no greater (as expected). Now it’s time to make some decisions because I can safely say we aren’t going to hit our (new) target on time:
I sit down with the client and re-visit the conversation we had a few weeks previous: they know it’s coming so there are no surprises. Because we can’t move the completion date and because it’s not efficient to add new team members (clients need to understand that efficient teams are not built in a day) it’s time to review the product backlog as we’ll need to remove some scope. Through the prioritisation exercises we performed before we started the first sprint (we like MoSoCoW) we’re able to remove 6 points now and a potential further 10 points are earmarked for demotion should it be necessary and we agree to see how the next 2 or 3 sprints go before making any further decisions.
Fast-forward 3 sprints and we’ve done pretty well, still averaging our full velocity. But it’s pretty clear we won’t hit the deadline equating to 22 points in 2 weeks (11 points a week has not happened so far so don’t except it to happen now – if you do then you, your client, your team or all 3 of you will be crying at the end):
It’s time to re-visit scope but because we’re prepared for this to happen we already know of 10 points that can be removed without sacrificing too much (and let’s face it, the client has his/her new wizzy gizmo that was introduced half way through the project so they’re happy). We agree with the client to remove one of the Medium user stories in the backlog, equating to 4 points. We also agree to put in some additional hours to ensure we can meet the deadline. The final 4 sprints look challenging but manageable:
And lo and behold, because the last few weeks were manageable and because we’re being flexible throughout the project and work with the client to make decisions to keep us on track, we’re able to deliver on time:
A word of caution
A theme running throughout this post relates to communication. The chart is not intended as a battering ram to speed teams up or to thrust in the client’s face when you realise you won’t hit the deadline because of new feature requests that you didn’t manage very well. It’s about using data in a clear and transparent way so that you can work together to make the decisions that will keep the project from derailing and ultimately delivering a great project within the constraints set out at the start.
When new ‘features’ are suggested, don’t fall into the trap of circumventing your normal validation process. Make sure that you follow your standard way of validating and refining user stories. The last thing you want is to drop already validated and prioritised user stories for stories that haven’t had the same treatment – if you haven’t relatively prioritised new user stories against the existing ones, how do you know which is going to deliver more value? You risk dropping stories that could potentially deliver more.
Help your client to understand that as a consequence of adding one thing you might have to take out another and so you need to be certain that the thing you’re adding is a higher value item than the one you might drop.
Whilst I realise this is a simplistic view of a project I hope it demonstrates how a simple chart together with valid data can help to inform decisions (and work with the customer) to keep things on track. Obviously if budget and deadline are more flexible then the decisions are different (for instance adding more sprints as opposed to reducing scope) but I’m not about to run through every possible permutation!