Know How Much to Commit to Before Committing

Story Point Estimation Versus Breaking Stories into Tasks

8 April 2014


Which comes first, story point estimation or breaking the user stories into tasks? Normally teams come up with the story points first, followed by tasking the user stories. But I would suggest working the other way around, because of the following:
  • It helps to know how much to commit to before committing work for the sprint.
Teams considering historical velocity for planning sprints may face a problem while committing for the sprint in case the story points of current-sprint user stories match their velocity, but the hours required to complete the user stories are more than the capacity.

I want to explain this with the following example:

"Team A" has a historical velocity of 25 story points. In the current sprint, they have identified five user stories, the sum of which is also 25 story points. As the historical velocity matches with the user stories that are in the current sprint, the team commits to all five user stories.

At the time of breaking these stories into tasks, however, the team finds that they need 400 hours to complete all the committed user stories -- but they have only 300 hours. In this scenario, what can the team do?

The only solution I see is to reduce the scope from the scope already committed.

At the end of the day, it's the availability of hours that matters. So the user stories that the team commits to should be based on hours rather than story points.

The other accrued benefit is:
  • While tasking the user stories, teams get to know lot of things about each user story that they would not have been aware of if they had estimated the story points first, which means that the accuracy of the story point estimation increases.
If the team first breaks stories into tasks, then follows that with story point estimation, they know how much to commit to before committing -- and the accuracy of the story point estimation also increases.


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 (1 ratings)

Comments

Anant Singh, CSM, 4/8/2014 7:33:01 AM
Nice article. It attempts to the address the age old issue of correlation between the story points and the hours for a user story. I agree with the sentiment but do not necessarily agree with story pointing to be done after hours based estimation.

Story points are used for high level release estimation as well. You cannot wait till hour based estimation to be done to work out approximately how many sprints will be required to deliver a release.

I agree with your example that this means that the story points delivered in two sprints may not necessarily be the same BUT they can't be way off each other either. If the story points delivered in two sprints are massively different then perhaps the reasons for this must be identified and the lessons be applied in the next sprint (after all this is what agile is all about). Or perhaps that's absoutely fine as your team is coming to grips with the new project and with the growing confidence feels can deliver more story points in the next sprint.
Zach Bonaker, CSP,CSM,CSPO, 4/8/2014 12:28:44 PM
Agree with the above comment - I believe an unnecessary relationship between points and hours is assumed in this article.

We allow points to represent a distribution of effort that will (likely) overlap from each point on the scale.

Points are terrific for release planning and predictability. But less useful for an individual sprint. In other words, get value from points in long-term planning, not short term.

Instead of fixing a sprint goal to velocity, try using a commitment-driven approach, instead. Take the highest value story, break it down, ask the team "Can we do more?" If yes, repeat until the team is satisfied. Whether the sprint goal is 4 points or 40 doesn't make a difference to the sprint timebox. In the long run, the velocity balances out.
Charles Cain, CSP,CSM,CSPO, 4/8/2014 1:18:40 PM
Agree with Anant and Zach here. The team should be trying to improve their performance and one way that they can do this is by challenging themselves to do more. This is a delicate balancing act each time the sprint is planned. Remember, we want the team to have a sustainable pace and not suffer from burnout.
Tim Baffa, CSM, 4/8/2014 3:42:51 PM
Difficulty seeing the point being communicated in the article.

Ideally, story points should be used for sizing user stories in the product backlog all the way through Sprint Planning Part 1, when the PO makes the offer of refined user stories to the team. During Sprint Planning Part 2, the user stories should be broken down into tasks which are estimated at a time-effort level. In addition, team capacity is evaluated for the upcoming sprint, and only at that point of understanding should the "commitment" of user stories for the upcoming sprint be made. The team should NEVER go off and determine the time component of their user stories after their commitment is made.

From the author's perspective, the same situation envisioned would result if the team went off and suddenly realized that three team members had vacations planned during the upcoming sprint, yet team capacity is never mentioned.

One final point, the team commitment is to each other to do the required work in the sprint to the best of their abilities, not to the Product Owner, and not to the Scrum Master.
Chandrasekaran Janakiraman, CSM, 4/10/2014 1:58:07 AM
A very nice article and very interesting comments. I cannot agree more with Zach's comment on using a commitment driven approach. In my opinion, the only part that I see different to the author's note and the comments is that the author likes to re-visit story pointing "after" doing a task based split up for user stories. It does give a good feedback to the PO as his top priority story taken up by the team need a re-look at story point. After all agile is all about getting frequent feedback.That does include the credits earned by the team. If story A and story B is pointed at 1 and it takes 60 hours and 10 hours for the team to complete respectively, there should be some mechanism for the team and PO to re-look and adjust the points. What this gives us is that, at time of release planning (with only total team capacity data on hand) it becomes much more predictable in terms of how many story points we "guess" could be done in each iteration...

You must Login or Signup to comment.