In traditional or waterfall project management, the project plan often forms the basis of a contract – we’ll have the agreed scope completed by an agreed date for and agreed cost. When change comes up, it inevitably leads to discussion on the triple constraint – which leg of the iron triangle is most important, scope, cost, or schedule. And, because we’ve been burned in the past, we’ve created elaborate change management processes that generate tons of paper, but very little business value. Every time there is a change, we need to update the contract – paperwork anyone? Put simply, change is a dirty word in a waterfall world.
By contrast, agile methodologies like Scrum are built for change. The Scrum process is all about managing change, or rather embracing change. The contract is intentionally more open ended. However that ‘iron triangle’ conversation is still just as valid. The difference in the agile world is that scope is inherently the most flexible leg of the iron triangle. If you accept the fact that you may not get every bell and whistle, cost and/or schedule are really easy to fix. The key is to prioritize the work properly and integrate early (one of the reason’s the product owner role is so important). When done right, the features that are left when you run out of time or money are the ones of least value that are likely not worth pursuing anyway. Tip: Release early and often.
The Fixed Capacity Approach – Simple, but Effective
If you’re familiar with Scrum, you know about story points and velocity. Story points are a measure of how much scope you have and velocity is a measure of how quickly you can complete that scope. From these two metrics you can derive a schedule, often referred to in Scrum as a Release Plan… In a fixed schedule/budget scenario, you can use the team’s capacity for a given release (i.e. how many story points can they complete in a given timeframe) to help manage the change to your backlog. Set a fixed number of story points, based on the capacity of the team. The product owner can change all the scope they want as long as the total doesn’t exceed the capacity for the given release.
For example, based on a velocity of 20 story points per sprint, the team will take 10 sprints to complete 200 story points. Said another way, the team has capacity for 200 story points in this release. If the product owner adds a new high-priority user story scored at 3 story points, then an equivalently valued, low priority user story must drop off the list. This approach to change management is similar to a fixed scope approach you might find in a waterfall project, except that the product owner is allowed to change scope all they want as long as the total story points doesn’t exceed the original/agreed amount. I refer to it as the ‘Fixed Capacity’ approach to agile change management. No change request needed.
Using Release Burndown to Quantify the Cumulative Effect of Change
That change request from your waterfall days did have a purpose, though, buried under all the paperwork – to quantify and communicate the impact of the change (i.e. cost, schedule, etc). Change happens more frequently and in smaller increments in agile projects, though. Applying the level of process and documentation around change that we typically see in waterfall environments is burdensome. With that flurry of small changes, you might still be writing change requests six months after the project was complete. Waterfall methods for documenting change are just not practical on agile projects, but then how do we communicate the impact of change to our stakeholders. This is where it gets good. I hope you’re still reading… 🙂
There is diminished value in evaluating the budgetary and timeline impact of every change to your product backlog. Instead, focus on the cumulative impact of all those small changes over the course of the project. When it’s time for that iron triangle conversation with your stakeholders, pictures tell it better. A diagram or chart that provides a summary view can facilitate the narrative around how a project has progressed and how that progression will impact the final outcome. In Scrum, this is where the Release Burndown chart comes in.
Those familiar with Scrum have likely heard of a Release Burndown…, but are you using it? It can be a good tool to help with those change management conversations – to demonstrate that cumulative impact. However, the basic Release Burndown lacks a few added dimensions that help to tell the whole picture.
For example, below is a typical release burndown chart. It shows how much work is left (expressed in story points) at the end of each sprint and provides a picture of overall progress. The current sprint is visually distinct to indicate that it is in progress, and any associated metrics are estimates. There is an additional trend line that projects that the work will be completed in Sprint 11. Pretty nice, right?
Well… then the product owner added some new user stories and still wants everything completed under the original schedule and budget. So, now your release burndown looks like this, and your stakeholders are wondering what is going on with your scrum team – what happened in sprint 4, why isn’t anything getting done, and why do you need another sprint? So, what’s missing?
After reading Mike Cohn’s article on “Alternative Release Burndown”, I started expanding my release burndown charts to more clearly show change, and it has really helped facilitate my change management communication. Start with the same burndown chart, but add in the additional scope changes as a new dimension, still expressed in story points, but graphed below the X-axis. The quantity graphed below the X-axis is the cumulative increase in story points and not simply a sum of the new user stories (you may have taken some out). My new release burndown still predicts the work to be complete in Sprint 12, but the added dimension more accurately reflects progress as well as impact of change. Note the trend line extends below the X-Axis to project when the additional scope would be complete, not just the original scope – the project is not done when you hit zero. The heaven’s open up and angels begin to sing…
Now you have something simple and powerful that can more easily demonstrate the impact of change as well as overall progress of the team. You can take this into a conversation with your product owner and other stakeholders and say “look the team is getting all this work done, but the cumulative impact of changes will result in missed dates and exceeded budgets.” A good product owner will say “I understand. Let’s prioritize the backlog and remove the lowest items to get back on track.” Isn’t this fun!
It slices, it dices… But wait, there’s more! Change never stops on an agile project. Is that truly my end date, or will more scope be added pushing the date out further? To help answer this, you can add another trend line to the graph based on the average increase in story points per sprint. Factoring in that average increase in total story points, the burndown chart below now predicts work will be complete in Sprint 13. This implies that scope is the most important leg of your iron triangle. I’d love to be on that project!
I’m a bit of a numbers geek, so I’ve added team velocity, total story points, and burnup to my charts as well. It can get a little busy, but it’s nice to have it all in one place for those stakeholder conversations. I will often compliment this with a simple log of user story changes throughout the project – title, story points, removed/added, date. I have yet to need it with any stakeholders, but it gives me piece of mind to have it.
In Summary
In Agile/Scrum, scope is considered the most flexible of the triple constraints (iron triangle) of Scope, Cost, and Time. Agile processes embrace scope change in a way that allows scope to fluctuate throughout the project. However, it is important to acknowledge that not all scope will, or even should be, completed. The goal should be to continually focus on the highest priority features and complete the work in such a way that allows a go-live decision at the earliest possible time (i.e. Minimally Viable Product). We typically see a multitude of small scope changes given the iterative approach to development, but we don’t explicitly track individual scope changes. Instead, we leverage story points, velocity, and release burndown to get a picture of how scope is changing at a macro level throughout the project. As work is added to the backlog and prioritized consider removing similar sized, low priority work in order to maintain the timeline and cost portion of the iron triangle. Use the expanded release burndown chart to help illustrate the cumulative impact of change and facilitate a dialog with your stakeholders around change management.
I worked up two versions of the Excel template, basic and extended. Anyone who may be interested can download below.
