We know that long term planning(Release planning) should be in story points.

But for sprint planning, it should be commitment based.

Breaking the product backlog item / user story into tasks and estimating the tasks, team asking themselves if they can commit to delivering the product backlog item, and then repeating until they are full?

For a three week sprint, how big should be each story for a person?

Also,I have seen that some teams do away with this task based planning and have stories that are just 2 day long?

Should I standardize this for my team?

So before a sprint, I break my stories to such short stories that they fit this standard.

Please, let me know your viewpoints about this. And what is the general practice?


3 Answers 3



Basically, your entire set of planning assumptions is non-agile. You need to revisit how you're planning your iterations, and how your team plans to estimate the work it thinks can be completed for the current iteration. A more detailed analysis follows.

Detailed Analysis

We know that long term planning(Release planning) should be in story points. [sic]

No. Agile release planning is done in iterations. Therefore, a Scrum project plan will estimate an approximate range of iterations needed to reach the minimum viable product or complete the initial Product Backlog. This is only an estimate, as the backlog contents will change over time, and length and accuracy of estimates will also change along with the Cone of Uncertainty.

But for sprint planning, it should be commitment based.

Again, no. Sprint Planning is capacity-based. The only point of tracking (or creating an initial guesstimate of) the team's average velocity is to find the team's sustainable capacity for work over time. While the team must be sure never to over-commit to work in a Sprint just because the velocity range or average says that there should be available capacity, it is the team's responsibility to plan for the current iteration by taking team composition, availability, and other factors that affect the present Sprint into consideration.

Saying that Sprints are "commitment-based" is likely to be used as an emotional bludgeon to get teams to commit to more work than they should, because of course team members should be "committed." However, that's a misuse; in the real world, team capacity should generally be reduced but rarely inflated during planning. If the team has under-committed, then additional work can be peeled off the Product Backlog as needed, but trimming scope is almost always politically fraught and often puts the Sprint Goal at risk. So, don't do that.

Capacity can be a relatively-objective metric. On the other hand, commitment (much like patriotism) can't be measured unless you're asking people to "make the ultimate sacrifice," which is sort of antithetical to the entire premise of agile sustainability. Never commit to a death-march.

For a three week sprint, how big should be each story for a person?

This deserves a whole book filled with "no." Stories are never sized for, or accepted by, an individual. All stories are estimated based on the full, coordinated resources of a cross-functional team working together to complete each story. The stories are accepted or rejected based on whether:

  1. They are essential to the current Sprint Goal.
  2. They will fit within the estimated capacity available for the current Sprint.

A single Product Backlog Item can be anywhere from 0 story points up to the maximum available for the entire Sprint. However, a good story that meets the INVEST criteria is generally composed of Sprint Backlog tasks of around 0.5 days to 2.0 days in length. Remember that the smaller the task or story, the more accurate the estimate usually is, so a dozen 5-point stories (when accurately estimated) are generally more reliable than a single 60-point story. However, your team maturity and estimation accuracy may certainly vary.


User stories are not per team member

Multiple team members should work on the same user story at the same time. This is not a requirement but a recommendation. The essence of the rugby terminology, scrum, where the team goes towards the goal line as a unit. The concept is called swarming. Everyone focuses on one (or fewer) tasks at a given moment, completes it, and tackle the next piece of work (repeat). Benefits:

  • It keeps_in progress_ items fewer.
  • It allows completion of sprint backlog items spread throughout the sprint, instead of everything being completed close to sprint end.
  • Keeps qa/testing load evenly distributed across sprint duration.
  • Whole team gets the code knowledge and may provide technical suggestions.

Team should pick a story and break it down into technical tasks. Only one person should work on one technical task because the responsibility is clear in this case which helps during daily scrum meetings. Ideally one technical task should be small enough so it gets completed during a day.

Size of user stories

Scrum does not define any recommended size of a user story. However a story should be sized such that it can be completed during one sprint. "Completion" means that it covers your "Definition of Done".

A story should be clearly understood and have explicit acceptance criteria, which is be verified during the same sprint. Normally it is harder to iron out a big story and spell out all the acceptance criteria, so a story should be small where it can be estimated well enough and tested.

A story should also be big enough so it delivers a concrete business value to the stake holders.

So the answer is neither too small nor too big. With practice and experience you get better in writing and splitting user stories. Its more of an art than science.


Sprint planning should be in story points as well. The process is the same as for the long term planning. You check your velocity and capacity (how many of the team members will be there, because of holidays etc.) and come up with a number.

If you are planning for sprint 2, you check your velocity in sprint 1 - for example 10 points - and put 10 points worth of user stories into your iteration backlog.

If you are planning for sprint 3, you check your velocity trend from sprint 1 to 2 and find the amount you can commit to.

If you you are planning for sprint 1, you add as much as you see fit.

Try not to see how many points a person can do, because scrum is about teams not persons. For example a junior can do less than a senior, however is people helping each other they won't be able to deliver as much as "on paper". Work and calculate with teams, because it makes more sense (and it is easier).

  • Yes , I agree to you , total storypoints of previous sprints to be referenced and as you/CodeGnome said, capacity is also to be taken into account.Actually , I am confused that how short should be "each" story so that it can be tested in parallel as there is no separate test phase.
    – Roop
    Commented Oct 22, 2015 at 13:55
  • Also , I have earlier referred following : mountaingoatsoftware.com/blog/…
    – Roop
    Commented Oct 22, 2015 at 14:51
  • @Roop, like others said , "each" story need not be short enough.It will be worked by multiple team members but tasks within the story should be kept 0.5 days to 2 days Commented Oct 22, 2015 at 16:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.