This video shows you how to use NextWave ScrumMaster’s interactive Burndown graph to estimate when a project will finish.
Closed captions can be turned on and off in the YouTube player. The video script follows for translation purposes, if needed.
VIDEO SCRIPT FOR TRANSLATION
Welcome! This video focuses on using ScrumMaster’s interactive Burndown graph to estimate when a project will finish.
NextWave ScrumMaster™ is a Windows 8 application designed for Agile scrum management.
Let’s load the demo project file. From the ScrumFunction toolbar…
• Click the cloud icon.
• Click to download the sample file.
• and head back to Home.
• Click to open the project file.
• Right click to open the apps bar.
• and select the Burndown graphs button.
The Burndown graph displays for this DEMO project.
Dynamically updated and displaying your latest data, it’s available any time you want to use it. Let’s review how it works.
Backlog story points are on the Y axis and Sprints are on the X axis. This scale changes as your project data grows and changes over time.
Here you can see:
• At project start, there were 200 story points in the backlog
• We currently have 324 story points in the backlog, the additional points coming from meetings held, differences between original and agreed upon story points, and any story point additions or deletions made since the project began.
• The dotted purple line connects the dots, the number of story points logged at the end of each sprint in the Retrospective, for example, about 210 at the end of Sprint 1, 240 at the end of Sprint 2, and so on. It gives you a quick visual reference to where and when the backlog grew, and you can use ScrumMaster’s Reports to pull data for a specific sprint for further analysis, if you need to.
• The blue line and triangle area below it describe burndown of a given number of Backlog story points at a selected target velocity, in this case, 324 story points at a velocity of 40. Although it often appears to look the same, the slope of the line changes with your data. Change projected velocity and you’ll see the X and Y axis scales change as a new sprint finish calculates.
• This yellow line is your actual velocity, reflecting the story points completed by the team so far. To date, the team’s completed 244 story points. The vertical yellow dotted line points to Sprint 5, the last completed sprint, which was completed on this date. And you can see at a glance, 80 story points remain in Backlog.
Ok, if all ScrumMaster did was track and display your project’s progress, this would be helpful, right? But it does much more.
Most Scrum Masters constantly have to answer the question, “When will this project finish?” Not a question easily answered. ScrumMaster lets you change 4 key variables and see the immediate impact on a projected end date… helping you determine the best answer to that question.
The four key variables are:
- Projected (or future) velocity assumed
- Velocity required to hit a given end date
- Confidence in the assumed velocity
- Confidence in the Backlog estimate
Click these arrow buttons to expand menu options. Let’s start with the first, with the project’s end date ‘Based on a future velocity’.
The extension of the yellow Actual velocity line tells you in which sprint the project ends. With 80 story points remaining and the velocity currently at 40, 2 sprints remain.
But, what if you anticipate a change in target velocity? Use this slide to select a different projected velocity going forward, or use the project’s history for a realistic value.
• Select the historical Minimum,
• the Average
• or the Maximum velocity ScrumMaster tracked for this project.
Keeping the numbers simple to emphasize the process, let’s make a few extreme projections to see the impact.
Let’s change velocity to 80.
• Check the result. Now it only takes 1 sprint to complete the project.
Note that the blue area (Burndown using project’s velocity) has changed too, but this late in the project timeline, it’s not very useful. All it shows is where the end date would be–barely into Sprint 5–had 80 been the targeted velocity throughout the project from its start, assuming today’s backlog of 324.
Now let’s change the future velocity to 20.
• It now takes 4 sprints to complete this project. The project ends in Sprint 9.
The blue area has changed again, representing what the burndown would have looked like for a project of 324 story points with its velocity set at 20. The projected ending sprint under those conditions would have been Sprint 17. Not important to us here but there may be times when this type of analysis is useful to you.
Next we’ll look at velocity impact when a specific end date must be met.
You’ve just been told the project MUST finish by a specific end date. So what is it going to take to make that happen?
• Select the ‘A line in the sand’ radio button.
• Simply change the date to your end date.
• The minimum velocity the team needs to meet to make the new date displays, in this case, 16. Obviously given the result and where you are in the project cycle could kick off more management conversations about how this can be accomplished. At least ScrumMaster gives you an easy visual tool to discuss ‘What if’ scenarios.
Let’s return to our original projected velocity.
You’ve assumed a future velocity of 40. But how confident are you about the team’s ability to meet this future velocity you’ve selected?
Click to select ‘Velocity confidence’ options.
• The Best case scenario is selected by default: you are confident in your estimate and no adjustment is made.
• If you are less sure, click the other options to add 5%, 10%, or 15% to your future velocity estimate.
With each selection, the results change right before your eyes.
• ScrumMaster will calculate the Best and Worst case sprint finishes, these dark grey and green dotted lines. Note that the yellow dotted line changes to grey, showing you the ending sprint now includes a ‘Projected velocity’ adjustment. In this example, because it close to the end of the project and the numbers are relatively small, a plus and minus 15% (or 6 story points) doesn’t show much variation in end date. But in the beginning of a project, the variability can be much greater, underscoring how difficult it is to come up with ‘accurate’ projections at project start that hold up over time.
Let’s keep the 15% adjustment and click to assess our confidence in our Backlog estimate.
• The confidence in the Backlog estimate by default is 0, but if you think more backlog items will be added or deleted, you can make a plus or minus 10% or 20% adjustment to your numbers. ScrumMaster does the rest.
• If backlog is modified anticipating adding points to the estimate, you’ll see your project’s Actual sprint velocity yellow line start from the new, adjusted backlog estimate. This may or may not result in a different sprint finish. In this example, if the backlog is very undervalued at 20%, 16 points are added to the existing 324. The new, adjusted backlog becomes 340 and the projected finish is now in Sprint 8, not in Sprint 7.
• Modifying the backlog to reduce backlog works the same way, in the opposite direction.
In all cases, calculations round to the next sprint, so if you’re even one story point into the next sprint, the line points to the end of that sprint.
Ok, so everything we’ve done has helped us define our projected finish sprint. Once a future velocity is selected, and we have defined our confidence in that velocity and the remaining Backlog estimate, we can also evaluate our Estimated Team Cost.
What is Team Cost and how is it calculated?
When you set up your project, in the Project’s profile, you set up:
• Average cost per team member
• Sprint variables that define work duration
‘Team cost per sprint’ only includes team members whose individual profiles have been defined as ‘Work effort reduces backlog‘.
• Note the icon under the team member’s name displays their work status.
• If you need to change someone’s work status, open their profile and click to toggle the change.
Using these variables, ScrumMaster projects ‘Team cost per sprint’.
• In this DEMO project example, 4 out of 7 team members’ work reduces backlog. Four times $8,000 results in a ‘Team cost per sprint’ of $32,000.
ScrumMaster calculates and tracks estimated team costs at the end of each Retrospective, using the actual data for that sprint.
• These costs are summed for ‘Actual cost of completed sprints’ here.
Using the numbers for ‘Sprints remaining’ and ‘Team cost per sprint’, ScrumMaster calculates ‘Cost to complete’.
‘Projected final cost’ includes these actual and projected costs. The Low and High estimates will vary only if your confidence ratings push project endings into different sprints. In this example, both Best and Worst case scenarios ended within Sprint 8.
Keep in mind that ScrumMaster is tracking general cost for this development team, not individual team hours or any other project costs. ScrumMaster is not a time tracking application. It is all about scrum, keeping track of what needs to be done, what is done, and when the project can finish. It’s designed to make your life as scrum master easier, and make it easier to be Agile!
Give it a go! Download ScrumMaster from the Microsoft Store. Check out Agile Story Sizing Cards for Windows 8 and Windows Phone too–these apps replace planning poker card decks and connect to ScrumMaster. Record team member votes automatically during your sprint planning meetings!
And be sure to visit us at NextWaveScrumMaster.com! It’s our global ScrumMaster community site.
• FB: NextWave Online Training
• Tweet: @NextWaveScrum @NextWaveOnline
• LinkedIn: NextWave Online Training
Thanks for viewing, and if you have any questions or feedback to share, please leave us a comment.
NextWave Online Training