In my company, there are 3 different development teams, newly started scrum. They mainly follow same path in doing scrum, but when it comes to sprint burndown chart, the act differently.
One team, gathered story points (with estimated points in them), broke them into tasks and estimated points for them too, i.e, a 10 point story may have 3 tasks with 4, 1 and 5 points estimated for them respectively. When they completed a task, they updated burndown chart respectively. The result, was a relatively smooth burndown chart, but in case of failed stories it was somehow deceptive; It showed progress that wasn’t actually made for the end user.
On the opposite side, other teams didn’t estimate points for tasks and just updated the burndown chart when a story fully completed. The result was a stair shape diagram: for some days team did no progress and suddenly made a big step.
The question is, what is the right way to make the burndown chart and which approach was closer to it?
Who is the audience for the burndown chart?
The second method, where you take credit after the completion of a story, is more in line with the ideas behind Scrum. There are several questions here on Software Engineering about dealing with incomplete stories (1, 2, 3, 4). A story, not a task, represents something of value to the user. If you take a step back and consider the sprint as a collection of stories and a commitment to deliver a certain amount of functionality, showing the burndown chart as indicating the completion of those stories is useful to the product owner and the user to show how close you are to meeting those commitments.
In the first method, where you take credit after the completion of a task, seems to be more useful for internal use, especially the Scrum Master and the project team. These are the people who think in terms of tasks and can use the information in this view as feedback to improve estimation and planning for sprints.
Consider using the right approach for the audience. If you aren’t sure, ask them and discuss it. Although it comes from the lean approaches, eliminate waste. Produce the artifacts and have the ceremonies that you need to be effective and work as a team with the other stakeholders to decide what those artifacts and ceremonies are.
Personally i prefer the first way. It gives you a better sense of progress and the “work” done. Also many times the division into “User stories” is somewhat arbitrary. I prefer to see how much work was scheduled into the current sprint and how much was actually done.
But it doesn’t matter. Each team should choose what suites them best. That’s one of the most fundamental ideas behind agile: the team finds the best way to measure and manage itself.
I can also see the motivation behind the second way. They care less about the actual work done, and care more about how much functionality and features they completed for the users. This seems more fitting to short and simple stories and to a simple project from a technical standpoint.