Here’s an example on sprint progress:
"The current graphic (Taiga’s Sprint Burndown Chart) is not valid for us because “burnt” points appear only when all the tasks in a given user story are closed, which means that during the first week of a sprint we get the impression that we haven’t advanced even though we are closing tasks inside various user stories.
The requirements we have from our Scrum Master is to work with the philosophy of tasks as a measure of what the team is doing and the real progress (they even account for hours)."
The Scrum Master they refer to follows the book. The official scrum guide in its section dealing with sprint backlogs says:
Monitoring Sprint Progress
At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the Sprint, the Development Team can manage its progress.
A well-known, and more in-depth development as narrated by Henrik Kniberg in his book “Scrum and XP from the trenches”, also speaks of accounting for the pending work in a sprint.
In both cases they talk about asking the team how much work they think it is still needed for every user story, be it in points or hours, then add them all and find how much it is still left of the sprint.
Implementation-wise, what this team is doing is accounting for the hours worked on completed tasks.
The progress of tasks in a user story does not give you actual information on the progress of the sprint, because if we are faithful to Scrum, during the demo we can show only finished stories, not ‘almost’ finished stories.
A graph of pending tasks in the sprint showing that 90% of the sprint is finished sprint, while really only 2 of the 8 stories are complete (25%), may lead to a false sense of comfort, and avoids something very important, which is to focus on finishing stories.
Besides this, by keeping track of tasks, and doing so in hours, makes it necessary that they be estimated at the start of the sprint with the effort that entails.
When back in 2010 we tried to do a faithful approximation counting the hours remaining in the sprint, we soon realized that there was a micromanagement that didn’t really add much to what the panel told us. The blockages that may have been present in a story can be detected just as easily during the daily: "You’ve had three days with this 2 point story. Is there a problem? " Is much more effective.
In our opinion, if you want to have a Sprint Burndown graph with more detail than is currently present in Taiga, I would recommend, as the literature does, that the team be asked during the daily: “How many hours do you figure you have left in your story?” It is much more realistic and independent of completed tasks. And with that information you could make a chart to hang on the board or on a shared doc.
If you’d like to automate the process, in Taiga, you can create a custom field, input the remaining number of hours and use that field to easily draw a graph.
