6

If sprints are on average 10 days, why is it often suggested stories be sized to 2-3 days?

Related Question: How to handle backlog-items that are longer than one sprint?

7
  • 2
    Where is that suggested? AFAIK, you should size stories based on story points, not days.
    – netcoder
    Mar 8, 2012 at 19:25
  • 2
  • 2
    Story points are tied to a unit of time, but they're not themselves units of time like hours and days are. They're units of relative time.
    – netcoder
    Mar 8, 2012 at 19:49
  • 2
    @blunders You have posted several questions about Agile lately, some good questions some bad. Nearly every one of your questions however is based on some bold, unverifiable assertion about Agile that you don't provide a reference for. Are you making these assertions up? Is a senior or manager telling you this?
    – maple_shaft
    Mar 8, 2012 at 20:17
  • 3
    @blunders: Considering there's only one assertion in the whole question, I'm not sure why you ask.
    – netcoder
    Mar 8, 2012 at 20:54

4 Answers 4

9

When estimating, longer tasks have more room for variability. Variability means a lot of things - someone gets sick and takes a day off, someone gets pulled into meetings, someone has to support another project, you need to timeshare resources with other people or teams...the list goes on. By reducing the timeframe for a given task, you are trying to reduce the time in which the people doing the work can be pulled away or blocked from doing the work that you are estimating.

This idea isn't unique to Scrum (or any Agile methods), either. It's a part of any good estimation technique for any engineering projects. Having finer grained tasks tends to yield more accurate estimates, and this accuracy bubbles up.

4

Do you have any references for the "often suggested stories be sized to two days on average"?

I have seen some people suggest that tasks should take at most one day to finish. The main point is that we are bad at estimating and the longer you estimate it will take to finish the task, the more likely you will be to make a mistake.

You can find more at:

http://www.xqa.com.ar/visualmanagement/2009/02/one-day-tasks

and

http://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415

1
  • Both in your answer and the links provided, you refer to tasks and not stories. I believe the question is about stories. I mean, it makes sense and all, but doesn't really answer the question.
    – netcoder
    Mar 8, 2012 at 21:24
2

why is it often suggested stories be sized to 2-3 days?

I really wonder where did you get this suggestion because it is wrong. There are generally two problems with this suggestion:

  • The estimation is done in days.
  • The suggestion dictates how much should your average story take.

Both these problems violate simple principle of estimation used in agile methodologies: you don't know upfront how much time you need to complete a story. You are only trying to compare size (complexity) of stories in your backlog and during planning meeting you commit to few most prioritized stories you believe you can complete during sprint. After the sprint completion you will review how many user stories did you completed and you can make assumption about the time needed to complete other stories - the more sprints you do the more precise the assumption become. As your assumption about real time needed to complete story improve your commitment will improve as well.

Because of that people use relative measures to estimate stories like story points or t-shirt sizes and compute average time needed to deliver a story point or other unit. With consistent estimation you should stabilize your average time to delivery a story point within 3-4 sprints.

Because the unit is relative you also don't need to use same scale for all projects. You usually start with a single user story you are most certain about its content and take it as etalon with some size. You will then continue estimating other stories by comparing them to your etalon and other already estimated stories to select expected size. In case of story point you will usually use some sequence of expected sizes like Fibonacci because as your story gets bigger in complexity it is more hard to estimate and contains much more uncertainty. Big stories should be decomposed as described in linked question.

0

The bigger the stories are, the less accurate your estimates are likely to be.

Personally, I would break them down even smaller than that.

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.