Burn Your Points Before They Expire
Story points, relative sizing, hours of effort, and more
7 August 2015
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.
How many of you have experienced situations in which your customer or your product owner asks, "So Jim, how many Dev points did you burn yesterday?" or "Team, I haven't seen you guys burning any story points; are you guys really working over there?"
I've even come across situations in which teams struggle to respond to this sort of question and finally stutter with an answer such as, "Hey Mr. PO, we burned five story points yesterday. We still have three points remaining to complete that story."
I've experienced questions such as these in organizations that are adopting Scrum for the first time or are new to Agile. Some are cases in which the ScrumMaster or product owner (PO) is assigned from the customer side or from a nontechnical background. But, come to think of it, a customer asking such questions makes sense, because their primary objective is to make sure that the project is delivered according to the Triple Constraints (time, cost, and quality), and to make sure that the product is sold in the market on time and is generating revenue as soon as possible.
In terms of Agile principles, are the above scenarios actually valid? Can you really give a count of how many story points you have burned? The answer is an emphatic no!
As we all know, estimations in Agile are based on relative sizing. The team selects a well-defined, reasonably sized user story (based on complexity or value) as the base story. The team then agrees on a story point value for that particular story. Let's say, as an example, story A is of size 2. Then the team goes through the rest of the stories in the backlog and, by comparing them with the base story, assigns story points to the remaining stories. This we all know. During sprint planning, the team then decides on the list of tasks required to complete each story and specifies how long a particular task may take in terms of hours.
So, another question that is asked frequently is, "Is there a direct relationship between the story point assigned and the number of hours for the whole story?" Again, no! You might have a story of 5 story points assigned with 20 hours worth of effort, and another story of 3 story points assigned 20 hours of effort. It all depends on the maturity of the team and the gut feeling of the team at the time of sprint planning and estimations.
I circle back to our previous question about story points burned. The team reports time spent on each task and updates the remaining time to complete each task, in hours. So the total amount of time left to complete a story can be calculated day-by-day by summing up the remaining amount of hours. This is what gets reflected on your burn-down chart. Nowhere do you update or change your initial amount of story points assigned for your story. So, the logical answer you should give your PO is, "I've burned six hours of effort yesterday, and I have three hours of effort remaining to complete task ABC."
Finally, what if the team is unable to complete a story during a sprint? Does the number of story points assigned get added to the velocity? For example, can we say out of an 8-point user story, we completed 5 points and that should get added to the velocity? Again, no! User stories that are not completed are moved to the backlog and reprioritized and reestimated. An unfinished story of size 8, of which a certain percentage of work was completed, may be reestimated to be of 5 story points now and thus brought forward to a subsequent sprint.
I hope this all makes sense. The next time someone asks you the questions at the beginning of this article, you'll know what to say!
Current rating: 4.3 (4 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.