Reality… average velocity changes throughout a project. For any number of reasons—level of work, its difficulty, spikes, staff changes, holidays, etc. No two sprints are the same in terms of content so it’s not reasonable to expect velocity to stay the same from one sprint to another. Therefore, it can’t be the only variable to use to predict your final sprint.
Backlog changes too. This is normal. It just makes project tracking difficult unless you have a tool like NextWave ScrumMaster™.
Reading Mick Cohn’s article, Alternative Release Burndown Chart, reminded us why we designed the interactive ScrumMaster™ Burndown graph to project and handle backlog, velocity, and end dates the way we did.
As Mike points out,
“For example, suppose a team had expected to make progress of 40 hours, points (or whatever) last sprint, but the burndown chart only shows net progress of 10. Was the team slower than expected, or was more work added to the release?
It’s important to know the answer to this question, because we cannot really predict when the release will be done without it.”
Absolutely, and Mike shows you how to handle it using Excel.
Or, you can let ScrumMaster do the work for you and then some. As you can see in the video, ScrumMaster automatically projects your ending sprint. It also shows you when, where, and how your backlog grew.
If you are using ScrumMaster, here’s how it differs from Mike’s Alternative Burndown Chart.
- Projections to finish date are simpler… and ScrumMaster does it all.
- Want to see the trend line to project finish? Choose the Average velocity menu option and you get the classic projection.
- Backlog is automatically adjusted at each Retrospective (purple dotted line). You don’t have to add anything.
- All task work is color-coded, Original work plus any new work (Added tasks, Issues found, Software bug, Spike, Technical debt, Meetings). There’s a ScrumMaster Report that tracks and analyses Backlog by type, by sprint.
- You can select confidence levels for velocity and backlog estimates, to make automatic percentage adjustments to the projected ending sprint. The greatest impact is usually seen early in the project cycle.
Make sense? Give us a shout if you have any questions or comments.