Welcome to the Simplilearn Community

Want to join the rest of our members? Sign up right away!

Sign Up

Agile question (re: Story point estimation)

Dwayne Hammond

Active Member
Regarding Story Point Estimation, the instruction provided live seems to conflict with the other learning content so some clarification would be appreciated.
An example was provided where two user stories were being considered (i.e. implementation of a credit card as a payment method). In the live class, it was stated that because one story (or credit card) had been implemented already, then the second should be reduced in estimation due to the learning already achieved, and the possibility of reuse of some of the code. In video based content however, instruction seemed to be that story point estimation needs to be independent of other stories… and estimations should focus on the effort that specific story requires independently of other stories. (an example of two "similar" stories was provided in the same manner as the credit card example)
In the second approach, the end result is the VELOCITY of the team may increase as time passes, reflecting the learning that has occurred and other improvements in efficiency… but we do NOT scale the story point estimation based on status of other stories. That is… two stories of independent and equal inherent effort should be estimated the same, with efficiencies potentially visible in improving velocity, but evening out over time for a velocity that will reflect that some stories have built in efficiencies from others. This "independent" treatment of story point estimation seems crucial to the validity of the velocity measure contributing to planning being more accurate over time.
Given that this seems a critical point to me, with user stories and their estimation a foundational element of agile, can someone please provide a clear and unambiguous description of best practice in this regard?

tim jerome

Well-Known Member
I spent a bit of time with the PMBOK, Agile Practice Guide, and more than a few articles over at scrum.org. This topic is fascinating, and will help anyone understand the parallels of planning between plan-driven and Agile methodologies.

The use of using story points in estimation is an agreement that although you need estimates, you know that providing dates and costs will either be confusing, or at very least will be constantly corrected. Therefore, you will be creating a unit that gives degree of scale, but not lock you into schedule. For instance, you create story points as 'buckets' - buckets of effort, complexity, and so on:

A 1-unit bucket
A 3-unit bucket
a 5-unit bucket
a 8-unit bucket

The individual story point doesn't mean anything, but the scale will help you organize the size, complexity and effort in nice ways.
I guess you could also use the following buckets:

Roller Skates

These are arbitrary units, but understanding them in relation gives you an understanding of relative scale.

Again - these are not good for providing dates or cost, but they're great for organizing and estimating. Once the team gets a few of these points out of the way, they can start providing a reasonable estimate to a story point.

What you're asking is, "Can I use this analysis of this story point to compare against other works' story points? I don't think so. There may be some historical or parametric attempt, but it'll be high level - and it is bound to change. The estimation may be good for the work being done, but for any re-use, you'll have to carefully guard your values with assumptions.

Agile is all about change. As with everything else in this methodology, the value of your story point is bound to change. Therefore, we will collect data and analyze, but it will be deeply hedged by our understanding that there are a lot of broad assumptions invested in the analysis, not the least being 'we figured this unit out by doing non-similar work'.

I'm quoting best practice here; certain environments may have very repeatable work that can use the same story point metric.

tim jerome

Well-Known Member
I always find the needed reference after I've posted my comment. The Agile Practice Guide (p. 66) says, "Each team has its own capacity. When a team uses story points, be aware that the number of story points a team can complete in a given time is unique to that team."

Dwayne Hammond

Active Member
Thanks Tim, but to be clear, if a number of similar but distinct stories are to be performed (by a single team), where completing the first (let's say its 5 story points) provides value that makes subsequent similar stories easier... does best practice say that these subsequent stories should be estimated as 5 story points as well (as that's what they would be if performed individually or if there was an issue discovered with the earlier stories implementation), or should they be estimated to reflect that future similar stories are made easier (like 5,3,3,3,1,1,1 if implementation was progressively easier)?

I think you are saying they should all be 5, as even trying to factor in the potential advantages/disadvantages of previously completed stories would go against the whole premise of simplicity and speed that is a big part of the advantage of this approach.

I appreciate that many of these things can be customized to suit the needs of a given team, yet I just want to confirm best practice in this regard, as the implications on the estimation process would be significant depending on this question of story independence.

tim jerome

Well-Known Member
Others please feel free to jump in.

Story points are a specific unit of measurement. The Story Point value will be agreed upon as you get used to the work.

When you're going through 'planning poker', you're breaking the work into units, or story points. One category will be a 3-point category, the other will be a 5, and 8, and so on. Then, as you get into the work, you work together to understand what a story point means in relationship to time.

You start with an abstract unit, and as you progress, like everything else in Agile, you refine your understanding and start putting attributes to the unit.

Imagine a group in a meeting, and the following conversation commences:

"This looks like a 3-story-point task."
"This task seems to be about twice its size, let's call it a 5."
"This one is big - it should be an 8. Should we break it into smaller pieces?"

You've sized and analyzed the work, without placing schedule estimates around it. You can prioritize and organize the pieces.

As you get into the work, you learn the size of a planning point, and use that to estimate the duration of all these tasks you worked on.