Posts

, , , ,

Estimating story from trenches

In today’s user story writing workshop my client asked me how do you estimate a user story?

To me, Complexity, Effort and Time are three key things we need to consider while estimating any user story. You look at the complexity of a story to derive the effort required to estimate the time it will take you to finish the story.

To use an analogy of carrying a log of wood from point A to point B:

COMPLEXITY: “How BIG and HEAVY is the Log of wood?”

EFFORT: “How much horsepower is required to pull this log?” This is where Story point comes in.

TIME: Say it takes 2 Horsepower, “how quickly can 6 horses move the log from A to B?” And this, we all know is velocity which can only be derived after a few Sprints.

Complexity cannot be seen in isolation and effort cannot be measured without knowing the complexity.

P.S. I can assure my readers that no animals were harmed in the making of this blog.

,

Is there a point in story point estimation?

Is there a point in story point estimation? How do we estimate accurately?

This is a relative size of the story compared to other story estimated by the same team – it has nothing to do with who is implementing it and how long it’s going to take. Story points are relative estimate, so that you know that 5 point story will take approx. 5 times longer than 1 point story.
Benefits are

  • Team’s velocity can be measured
  • Allows team to plan future sprint without over/under committing and forecasting total number of sprints. As a result no unrealistic expectations are placed on the team
  • Helps team to focus on completing dev and testing in the same sprint
  • Helps teams reach a sustainable pace and due to this the business starts to believe in the teamHours (or ideal hours) are more about time estimation. It can lead to several problems:
  • Your “hours” are not the same as mine. It can be harder to make team estimate during release planning.
  • It’s easier to make relative estimates and then calculate team velocity in points.
  • Stories are usually decomposed to tasks for the sprint. These tasks can be implemented by different people. So total effort is not simply calculated as sum of task estimates.
Usually it’s recommended to make story estimation in points for release backlogs and in hours for sprint backlog.
  1. Story points are a pure measure of size and complexity
  2. Story points are relative (say, with respect to the simplest story) and so have a much longer shelf-life
  3. Story points are usually independent of who gives the estimate (as in, an experienced developer and an apprentice can usually agree on something like complexity fairly quickly)
  4. Story points avoid the need for discussions like “what are *ideal* hours, really?” or “My ideal hours are different from your ideal hours, stupid.” These add no value.
  5. Story points don’t influence behaviour (e.g. Parkinson’s Law)
  6. Story points are easier to work with – especially when product owners start to wonder why “3 ideal days take a week…”
  7. Story points are more fun – especially when they’re in units like gummy-bears, polar bears, or other endangered species.