[Agile Guide] – Estimating User Stories in Agile

As a developer, we have the toughest role throughout the project lifecycle: Estimating our work.┬áThe business (typically) puts so much at stake onto the developer for elaboration and understanding about the time and schedule of a project. It’s a tough life for a developer.

But fear not! There are resources to help you estimate your stories.

One great article we recently found was by Nicole Rauch, she states when when estimating a story you need to take into account several things:

  • Complexity: Consider the size of the story.
  • Risk: Consider the teams inexperience with developing this story.
  • Implementation: Consider the implementation factors.
  • Deployment: Consider the deployment requirements.
  • Interdependencies: Consider other outside issues.

We would add that developers should begin (over time) to develop a baseline for estimating sizes of stories. Use examples of past stories that can help developers understand relative sizes. Ask questions like: “How does this story compare to X-story we did before? Bigger or smaller?”

Now, the question really is whether you use points or hours for estimation. Mike Cohn suggests to use points for product backlogs, and hours for tasks.

Bottom line? Agile estimation is an art form that grows better over time. As your team matures and developers a solid baseline for estimating work it can produce a consistant cadence or velocity that is (somewhat) predictable for the long run, but not great at estimating short durations.

Find out more:

Agile Estimation and Planning- Peter Saddington

[HT: pBoop]

8 Responses to “[Agile Guide] – Estimating User Stories in Agile”

  1. Jay Decker
    March 16, 2011 at 4:06 pm #

    Another point to be aware of, if your story is “too” large, aka an Epic, you’ll want to break it down into more sizable tasks and estimate those individually. This will allow for greater accuracy when considering the factors above. As a heuristic any story that takes more than 5 days should be divided before conquered.

    • peter
      March 16, 2011 at 4:08 pm #

      Great point Jay. Thanks!

  2. Armin Weisser
    March 17, 2011 at 5:18 pm #

    For me the factor “Risk” is also related to the question:
    What impact does this user story have on the existing code?
    How well does it integrate?

    Do we have to change relevant parts of the domain model?
    Will there be migration issues?
    Is there a crusscutting concern that will lead us to change other parts of the system?
    Do we have to change/refactor our “big picture”?
    Does the technical solution can reuse existing code parts?
    If so, do we have to generalize and modularize existing code?

    The problem is that the team can’t always predict every impact while estimating. So at least it has to measure the cost in terms of risk.
    Agile is about increments. So, when the team implements the 10th of 100 user stories it’s very hard/impossible to follow the open close principal at once and everywhere, so that existing parts can easily be modified during future tasks. The consequence is, that a user story 99 will lead to modifications of components that are implemented during user story 10. The more components are potentially affected the higher the risk for user story 99.

    • peter
      March 17, 2011 at 5:19 pm #

      Armin, great questions to ask. Thanks for the helpful tips!


  1. User Stories: My knowledge bank of “value”able reads « Spice of life - March 27, 2011

    […] http://agilescout.com/agile-guide-estimating-user-stories-in-agile/ […]

  2. [Guide] – Create the Perfect Agile Workshop | Agile Scout - April 5, 2011

    […] main purpose for this workshop? Is it an informative workshop, and educational workshop, seminar, working session? Create a goal statement that you will share with your audience so they know exactly where you are […]

  3. Agile Estimation is Dead – Stop Estimating Stories? | Agile Scout - June 21, 2011

    […] been reading a lot lately about “not estimating stories in Agile…” or “why you should stop estimating all together.” – To be frank, […]

  4. Algorithmically Estimating Developer Time » Agile Scout - September 1, 2012

    […] get more accurate over time. When I began reading it, I simply said to myself: “Well if you estimate over time… the averages should just come out in the wash anyway…” This could be […]

Leave a Reply