Burndown Chart

User story point is relative not real size.
As a Scrum Master, if you are, you shoul coach your how to estimate.
Estimation is not only to know the size of a user story but the details of the user story via interactive communication between PO and DT.

For your reference:
http://www.amazon.com/gp/product/0131479415

Hi Raja,

As mendtioned by Ching-Pei a user-story point is relative, not real size. The raw value we assign is unimportant. What matters are the relative values. A story that is assigned a two should be twice as much as a story that is assigned a one. It should also be two-thirds of a story that is estimated as three story points. Essentially it is subjective measure of the amount of effort, complexity and risk involved in developing the feature.

If your team is having challenges in estimating using story points, an alternative option is to use ideal days - not to be confused with elapsed time.

Jitesh

For the purpose of a burndown chart, the 2 usual units to burndown are hours and story points.

In my experience, burning down story points is a much better indication of progress. Although hours gives you more granular measurement of how much is left, story points only score when something is Done ("working software"), which is the key measurement we want to look at. Hours can be wasteful and misleading, in that you could have 95% of your hours burned down but no stories actually Done.

BD shows the remaining effort to complete committed stories. Although story points are relative, but BD is based on effort, which you derive at task level against each story, Story points get credited ONLY when story meet DOD, however to track where you are in sprint, you need Hours\days left vs. remaining effort, hence both elements are important to derive useful information during sprint and post sprint. Well story points are being decided during sprint planning using the fibonacci series i.e 1, 2, 3, 5, 8, 13, 21, 34 and afterwards team break down stories into granule tasks & effort to match with sprint capacity.

Tracking and showing how sprints go can give a lot of interesting insights about team, product, organisation. Even that team is just starting with scrum having real data and track records can bring additional tool to coach team and join the dots about team decisions and effects.

I think you can find couple of options how to show how sprint looks like:
- burndown of story points left
- burndown of stories left
- burndown of sum of tasks left
- number of days left to end of sprint
- scope changes

With immature teams I'm usually focusing on proper refinement and good planning - to create self-confidence and good plan how to approach PBI in sprints. Sometimes it's easy then to spot lack of work together, too big wip and communication issues when comparing created plan vs reality. No matter which type of visualisation you pick, you need to keep it for some time and be able to answer team questions about purpose and expected results - just not to have burndowns because it is recommended.

I usually bring also quality dashboards - like test results, bugs in queue etc to have radiators with important data in place.