If you have worked with agile for a while, or have worked with a coach that has worked with mature teams, you will sometimes hear the question “why don't we burn-down story points instead of tasks?”

In fact, there is no problem in using story points as a burn down instead of hours, but in general I've found it to be a practice for more mature teams who are used to making and meeting commitments. We don't usually start that way for a number of reasons:

1. People new to agile do not think in terms of delivering end user value and so think in terms of tasks. They also do not think in terms of team but rather focus on “my dev task”, “my qa task” and so on. And people have a lot of problems understanding the waste associated with traditional estimation and how the relative sizing approach that we start with in Agile works. So the idea of separating stories / points / velocity from tasks / hours / capacity allows a level of abstraction that helps people get comfortable with the process, focus on value instead of tasks, and start thinking about team instead of individual.
2. People new to agile have a tough time understanding that we want end user value delivered every couple of days. In other words they are used to doing a lot of dev, then handing of to qa etc. if they take this thinking process into agile iterations etc, they end up creating waterfalls either within the sprint, or worse still between sprints. Creating small tasks to definition of done helps teams overcome this problem. It is natural then to want to burn those tasks.
3. People new to agile and when confronted with work will naturally fall into their traditional specialization roles which means that there is no team work (it's just a group of people) kicking off anything that allows them to be busy, rather than focusing on value delivery. By tasking things out there is hopefully a discussion about how we can better deliver this as a team as well as increasing learning / cross fertilization. Again if you have the tasks then it is natural to want to burn them.

But as said, if you have a team that does not exhibit the problems and issues - they commit and deliver as team to small slices of end user value - then there is no problem to burn stories. Some teams as an interim step do the tasking to make sure these things are being addressed and then burn stories to make sure they are delivering value of a regular cadence. Others burn both (eg Jira has a chart that shows both a story and task burn down, one on each access). In fact there is a benefit in that you hopefully get teams to focus fully on stories, delivery one at a time, per the ideal scrum approach.

NA