Get certified - Transform your world of work today

Close

Using Story Points in Burn-Down Charts Instead of Hours

15 July 2015


The Scrum process recommends that you use story points for evaluating the size of user stories so that each team member can agree on story points instead of hours. A Scrum team commits to a finite number of user stories that must be completed during each sprint.

During sprint planning, we usually generate child tasks for each user story. Up to this point, all is OK; for the planning part, however, we usually ask our Scrum team about time estimation for each child task to assign estimated hours. This is when we more or less have already decided who will work on which task, because estimated working hours are dependent on individuals.

After the estimation, we generate our burn-down charts based on hours. We notice (unfortunately, too late) that estimated hours are not always perfect, and whenever you must switch a task between team member A (who made the estimation during the sprint planning period) and team member B, it becomes yet another story.

It's not a good idea to map each story point to working hours; it conflicts with the reason for using story points. To solve our problem, we can nonetheless do something similar. The solution is to not model the story points in detail but to define them at a higher level and in a reverse way.

The main function of a burn-down chart is to reflect how the team performs during the sprint. The only thing that the team commits to in the sprint are the selected user stories. The team is also aware of the total number of committed story points. What if we go one level deeper and try to split estimated story points to the user stories associated with the child tasks?

Let’s illustrate this theory with a real-life scenario. Suppose your sprint duration is two weeks (ten workdays) and your Scrum team consists of four team members (TM):
  • TM_A works six hours per day.
  • TM_B works six hours per day.
  • TM_C can only work three hours per day.
  • TM_D works six hours per day, but TM_D will be on vacation for the last two days of the first week.
The team has committed to completing three user stories (US) for the total of 16 story points (SP). The team also defined child tasks for each US and split the estimated SPs to their child tasks, too.
 

The table below shows the sprint planning by hours.
 
  DAY_01 DAY_02 DAY_03 DAY_04 DAY_05 DAY_06 DAY_07 DAY_08 DAY_09 DAY_10 END
TM_A 6 6 6 6 6 6 6 6 6 6 60
TM_B 6 6 6 6 6 6 6 6 6 6 60
TM_C 3 3 3 3 3 3 3 3 3 3 30
TM_D 6 6 6 0 0 6 6 6 6 6 48
Total Daily Hours 21 21 21 15 15 21 21 21 21 21 198

It looks as though the teams will work for 198 hours in total and complete 16 SPs. So under ideal conditions, each working hour is equal to 16/198 SP. Now we can add two more lines to our table, such as:
Daily SP (expected SP per day) = Daily Hours X Sprint SP Total [16] / Sprint Working Hours Total [198]

Below is the ideal remainder SPs for the ten working days.
 
  DAY_01 DAY_02 DAY_03 DAY_04 DAY_05 DAY_06 DAY_07 DAY_08 DAY_09 DAY_10 END
TM_A 6 6 6 6 6 6 6 6 6 6 60
TM_B 6 6 6 6 6 6 6 6 6 6 60
TM_C 3 3 3 3 3 3 3 3 3 3 30
TM_D 6 6 6 0 0 6 6 6 6 6 48
TOTAL 21 21 21 15 15 21 21 21 21 21 198
DAILY 1,70 1,70 1,70 1,21 1,21 1,70 1,70 1,70 1,70 1,70 16,00
BEGINNING 16,00 14,30 12,61 10,91 9,70 8,48 6,79 5,09 3,39 1,70 0,00
 
So our burn-down chart is going to look like the following illustration:
 
 

Now we can reduce the SPs in our daily Scrum meetings according to the progresses of the child tasks.

Because the entire team agreed on each user story size, from now on it shouldn't be difficult to identify who is going to work on which task. This also means you don't need to assign tasks to team members during the planning period anymore. As a result, your work environment is more likely to be a "pull" environment instead of a "push" environment. In a pull environment, team members sign up for tasks, and the backlog serves as the source for the next few product items in the sprint. In a push environment, tasks are assigned to team members.
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 2.7 (3 ratings)

Comments

Kapil Goel, CSP,CSM, 7/19/2015 2:24:24 AM
@ Idris, excellent article and sharing.

See if you share any real time example, where each task was having a SP associated with it and how exactly team mindset changed with the suggested approach? How did the team took this approach?

I would like to add my 10 cents -

1. While assigning the SP to each tasks, it should be relative to other tasks under same story or other stories

2. Better if all possible tasks gets listed down in sprint planning meeting itself.

3. Break up of each tasks and sum of it should get matched with overall User Story Point,
It may add an extra overhead to the team, and would require a team coordination, may take 2 hrs of extra time for each sprint.
Scrum master can create a table, for each sprint, which can give the daily capacity of team by story points

4. By looking at Burn down chart, PO is having a direct feedback to slice the similar user stories further for future sprints.

For example here -

story with Point 2 - completely burning in 1 to 2 days approx.
story with point 3 - completely burning in 2 days approx.
story with point 5 - completely burning in 3 days approx.
story with point 8 - completely burning in 5 to 6 days approx.

This shows that Story with 8 point, can be further broken down into smaller user stories (considering the fact its a 2 weeks sprint)


Looking forward to putforth other experts view as well :)

Keep Sharing !!
Kapil
Tim Baffa, CSM, 8/13/2015 11:31:01 AM
This is of course what I view to be a best practice, but in my opinion, I try very hard to refrain from any estimation outside of the story level. To me, it just seems to be a wasteful activity.

Tasks certainly need to be defined thoroughly for each story, but there isn't any need to determine how long the task should take, or to come up with a story point value for the task that somehow rolls up to the actual SP estimate for the story.

If a team estimates a story at 8 points, then it is an 8. Have the team create whatever tasks need to be done for that story (2, 3, 12), but the overall story "scope" is still an 8.

Agile Principle #7 "Working Software is the primary measure of progress".

It should not matter if 3 of the 5 tasks for a story are done. Is the story done? If not, then it doesn't matter what progress is made on the tasks. When the story is done, then count the 8 SP as complete.

The suggested approach in this article seems to me to be reinforcing measurements and metrics around "stuff" that we shouldn't be tracking at all. Teams should not get any credit for "tasks" completed. The business doesn't care if 5 of the 7 tasks were done in a sprint - they only care if the story as agreed to was finished. And that should be all we care about as well.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe