Teams new to Scrum frequently push back on the Scrum rituals and the updates. The most painful of these is updating hours left. In my experience, and that of a few of my colleagues, the hours reporting may be perceived as management keeping the team on a short leash and micromanaging. There may be other reasons, but it's very common for the team to miss out on tasks updates. Moving to Scrum requires a lot of effort in culture change and in acquiring new habits. Process change is the easier part.
So I experimented with simplifying the task updates for sprint burn-downs. We were using Rally, which provided pretty good UIs for task updates and sprint burn-downs, etc. This team was used to monthly status reports and informal chat before being told to adopt Scrum. They found the daily update of task estimates to be highly irritating. So we considered few options:
Team members update tasks every two days.
Team members provide task updates every time the estimate changed.
Team members update tasks when they get done.
For various reasons we selected the third option; it's also the simplest. Everything else was done exactly as recommended by Scrum. Breaking down stories in tasks, making estimates . . . the results were pretty good. The burn-down was a good approximation to the Sprint burn-down using daily task updates.
Could we simplify the daily task updates even more? Here is the Excel spreadsheet simulation for an even simpler form of Option 3 from above:
The sprint planning meeting creates the sprint backlog stories based on velocity and story points. Let's see what happens if we do not track task hours left, but only track how many are remaining.
6-person team; team capacity in hours/day = approx. 6 * 7 hours /day
Team updates tasks only as they complete
The Tasks Remaining line was scaled to the same range as Hours Remaining for convenient visual comparison.
The team works on a few tasks until they are complete and then picks up new tasks.
Task estimates were created using random numbers between 4 and 16.
Line 1 plots Total Hours Remaining, when task estimates are updated every day.
Line 2 plots Number of Tasks Remaining, when the team updates tasks as they complete them.
For the same simulated sprint, if we track the Tasks Remaining
it gives a pretty good approximation to the trend line that we get from Hours Remaining
. There are a couple of observations we can make here:
At the end, the Tasks Remaining line becomes rather rough. We have fewer discrete tasks remaining toward the end of the sprint and so changes are probably not as smooth (statistically speaking). On the other hand, the Hours Remaining line is still rather smooth.
As we get to smaller and smaller tasks, the two lines will be closer and closer together. The blue line is the idealized hours burn-down; theoretically if each task were one hour each, the blue and the red lines will be the same. Using 4- and 16-hours tasks, it still produces a close enough trend.
If the team follows the guideline of small tasks, tracking the count of Tasks Remaining provides a very close approximation of the progress trend
. It may be less painful for new teams to update task completions only and then switch to the full task hours update when their Scrum skills get better.
We can use all task estimate = 1 hour in an Agile software tool and mark the hours estimate as 0, when a task gets done. Watch the Sprint burn-down and this may just be good enough for your project.