The Scrum guide states the requirement for monitoring progress toward goals. For example, it specifically mentions monitoring Sprint progress on inspecting progress toward a spring goal.
However, while the guide states the requirement, it does not prescribe any techniques or tools for doing so, leaving this to individual scrum teams to resolve.
This post will discuss how to sprint progress might be monitored by sprint board, velocity, and burndown chart.
The scrum guide says that the spring backlog is a plan with enough detail to understand changes in progress in the daily scrum. It does not tell you how to do that, though it is up to these developers to choose an appropriate technique.
Scrum Board
One of the most common tools is the scrum board.
Here in the left-hand column, you can see the sprint backlog items that the developers forecast to get done in the sprint.
They are placed in order with the most important of the top. Product backlog items are often returned on index cards. Each product backlog item is broken down into tasks or the tasks reported back right are initially placed into the to-do column. Tasks are often written on sticky notes. Each task is a separate activity that any member of the developers convulsant here to do. Once work starts on the task, it is moved into the doing column. When the task has been done, it is moved into the done column. This continues until all tasks have been done, whereupon the products backlog item is assessed against the definition of done, and If the work is done, the product backlog item is also moved into the done column. It is the responsibility of developers to update the task board as the tasks on product backlog items move through the various stages. The scrum board then provides an immediate view of the current state of progress, which is readily understood.
Velocity
Per Oxford Languages, velocity defined (noun) as the speed of something in a given direction. Velocity is an average of all previous sprints completed story points. For example, assume that the scrum team continuously split and refine all product backlog items until the rule roughly the same size. The amount of work they get done in a sprint then is the sum of all products backlog items that were done within a sprint. If they get 25 product backlog items are done in Esperance, their velocity is 25. If they get 12 product backlog items are done, their velocity is 12 and so on.
Velocity is an example of empirical data. It measures what we have been able to achieve. We use this to inform any estimates, forecasts or plans that we make. Common places where velocity might be used:
Includes spring planning, where velocity is used to guide the development team on how much work to take into the sprint.
Product and release planning where velocity can be used to answer questions such as When will it be done and how much will be done by a certain date?
Burndown Chart
A graphical representation of work left to do versus time is the Burndown Chart. The burndown chart provides a day-by-day measure of the work remaining in a given sprint or release.
Here is a sample burndown chart for a two-week sprint.
The team have taken 20 story points into the sprint shown on the vertical axis. They have plotted the two weeks (10 days) of the sprint along the horizontal axis. The orange-coloured line is a trend line. This shows the perfect work burn rates to go from 20 to 0 in two weeks. We use the trend line to see whether our actual line coloured Gray in this instance is getting work done. It is an inappropriate rate. The chart is usually updated just before the daily scrum, so we can immediately see how likely we will deliver. If our actual line is above the trend line, we may be overcommitted. On the other hand, if the actual line is below the trend line, we may have spare capacity. Also, developers should collaborate with the product owner, to add or remove work, as necessary. This is one technique the scrum team can use to fulfil their obligations of measuring progress.
Conclusion
Unfortunately, sometimes the scrum master performs administrative duties on behalf of the scrum team because they want the development team to deliver the product increment. But this is one of the worst things which scrum master can do. Let me put in this way, if the scrum master always updates the progress, what the team do when the scrum master is away. Let’s take the daily scrum as an example of the Daily Scrum’s purpose is a Plan work for the next 24 hours to optimize the probability of meeting the Sprint goal. The scrum guide also says that developers use the daily scrum to inspect progress toward the Sprint Goal and inspect our progress is trending toward completing the work in the Spring backlog. My point here is that if developers do not know how to update their chosen technique, how can they assess their progress? Or how progress is trending? So, scrum master must encourage teams to update their progress. I see this as an important part of self-managing.
Scrum teams need to monitor progress, examined progress trends, and produce forecasts and estimates. But scrum does not prescribe how this should be done. However, here are some commonly used tools: the scrum board, burned down chart and velocity.
My advice then, in simple terms, learn how to use these tools. Would you blame a compass for sending you in the wrong direction? Or could it be that you need to learn how to use it? A hard but important thing to admit. Please do not blame the techniques for your failure to understand them.
Take a minute to follow me on Twitter if you enjoyed this post and want to see more.
Leave A Comment