[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 Replies to “[Agile Guide] – Estimating User Stories in Agile”

  1. 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.

  2. 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.

Leave a Reply