Do you ever get tired of being asked, “when will it be ready?” Are you always hesitant to commit to a deadline so you can avoid being accused of being “late” when you don’t hit it? Because let’s face it, when you start to build a piece of software or a big feature you can’t easily decompose, you can never really say with any certainty how long it will take. You could spend a lot of time trying to anticipate all eventualities up front – but is there anything that sounds more waterfall than that? By the time you’ve done enough to be certain, you might as well have spent your time building the software.
Agile vs Waterfall
Long-term planning in an agile environment can seem like a paradox but what if there was a way to do long-term planning while still retaining agility? Scrum advocates planning no further into the future than the next sprint (1-4 weeks) but this simply isn’t how most businesses run; especially if they don’t have a culture built around delivering digital products.
Scrum is a great way of organising software development teams but it doesn’t answer the sorts of questions that CFO types love to ask like “how much will it cost and when will I get it?” This is doubly true in organisations that haven’t always built software and who are now under pressure to have a digital presence – organisations which need to build digital products and do so well if they’re to avoid being outdone by the startup crowd. If your business is building bridges or space shuttles, planning as you go along simply doesn’t wash.
Managing Stakeholders
Talking about the project manager’s favourite; scope-quality-time/cost triangle is one way to manage these seemingly conflicting needs between engineering and the business, but it can be quite a difficult concept to convey if your stakeholders haven’t worked with software development teams.
The Project Manager’s Triangle
Source: smarterwebsiteowner.com
The triangle paints a picture of a world where your only choices are between an underspecified or poor quality product versus one that meets all its targets apart from cost and time. In this world, business plans are built on clairvoyance: but what if someone told you there was a tool you can use to remove some of that guess work? Enter the release burn-up.
The Release Burn-up Solution
I’ve found it’s a solution that addresses how you make a commitment to spending the resources required to fulfil your business plan without pretending that you know what exactly you’ll get for that investment. It also avoids binding you to an impossible, inflexible scope and deadline which you can only ever hope to meet by compromising on quality. Or simply over-inflating your initial estimates for contingency, to the point where you might be unlikely to get approval to proceed in the first place.
How to do it
The release burn-up shown above can easily be created. Its components are as follows:
- Backlog – this is the solid blue line which indicates your best view of all of the work you have to complete to ship a product. You get it by adding story points of the stories you’ve already completed and your best understanding of what’s remaining in the backlog. It goes up and down and changes with every sprint as you re-estimate stories and add or remove stories/epics from your backlog
- Projection – this is the solid grey line showing what your ideal velocity needs to be to hit your preferred delivery date
- Actual velocity – this is the solid green line which includes your actual progress up to the present and a projection into the future (based on average from the last three or four sprints). The projection helps you to see whether you’re tracking to your ideal delivery date
- The dotted lines show what would happen if you were to work at a rate faster or slower than your current average velocity. Where they intersect the blue line is when you might expect to deliver your product
Other key Ingredients
The burn-up release won’t solve all of your stakeholder management challenges on its own. In fact, it relies on a few key ingredients to be effective, namely:
- A good roadmap which describes where you’re going if not necessarily the features you’ll be tackling at specific times. Roman Pichler’s goal-oriented product roadmap is a good template for communicating your high-level objectives in a transparent, flexible way
- A layered backlog – which includes granular stories ready for the developers to work on. But it also includes a high-level map of all of the epics you might need to complete for a fully-featured product. This map need not live in task management tools and in fact, is probably easiest to understand in the form of Post-Its on a wall like MTP’s own Janna Bastow’s product tree
- Imprecise estimation – all of these high-level epics in your backlog can be given coarse estimates with the understanding that there’s a lot that’s uncertain and these estimates will be revised in the future as you understand more about what you’re trying to do.
- A fixed, stable team working at a regular cadence so you can say with a high degree of certainty and precision, just how much you can do and what your velocity will be from sprint to sprint
The Best of Both Worlds
A release burn-up isn’t a silver bullet that will solve everything but it does allow you to be empirical and transparent with your predictions. These still need to be communicated carefully so as not to bind your team to the fixed date and a fixed scope they were trying to avoid in the first place. It needs to be heavily qualified with words like “things change” and “this is our best current view”. It definitely pays to prepare your stakeholders for a complete change in direction should new information suggest that it might be the right thing to do.
Similarly, it should also be clear that a team’s velocity ebbs and flows for all manner of reasons and an honest conversation about why that may happen is essential. Velocity is only useful in helping the team to improve the predictability of their output. It shouldn’t be used as a performance metric where not hitting a specific number indicates some kind of failure even when there are good reasons behind fluctuations.
Ultimately, stakeholders are only difficult to manage when they aren’t regularly reassured that the things they care about are in consideration. The release burn-up isn’t a replacement for communication and it doesn’t work on its own without other tools; you still have to do this bit yourself.
But it does reflect how modern software development teams actually work – which is to adapt and change direction as more information emerges rather than stick to a fixed view. In the right environment, with the right complementary tools, I’ve found that the release burn-up can be a really effective way of combining goals that seem at odds: carrying out realistic long-term planning without taking away agility or flexibility. And in my eyes, any idea that offers even a small chance of achieving this is worth exploring.
