15

Story Points (SP) is a good measurement, that allows estimating User Stories.

SP (in my understanding, it's an important note) is convenient because it is relative and not related with time. All estimates are based on comparison with a common basis. But what if two stories have completely different bases?

For simplicity, let's look for an example that is not related to any specific area. Like digging a pit.

Let's assume, that it will take 1 SP for digging a pit one-meter depth. Accordingly, we need 2 SP for making a pit two meters in depth. Very convenient. We don't care about our equipment. If we have a shovel then 1 SP will map to 1 man-day. If we have an excavator then 1 SP will map to 1 man-hour. But two meters pit anyway will take to us twice more time then one-meter pit.

All is good with pit digging. But what if the next story is "catching of an elephant"?

  • Should we make estimation with another (elephant related) basis? In that case, we will have two kinds of Story Points, which will be absolutely different.

  • Or, if we know, that 1) catching of one elephant will take for us 1 man-day 2) we still use a shovel for digging, then we should estimate this "elephant" story to 1 SP? This suggestion sounds absolutely wrong to me. But I wrote it because in my practice people use this option in most cases.

  • Or, maybe, I just misunderstand the concept of Story Points?

Improve this question
3
  • This is a very good question. But IMHO it has no answer becuase Story Points is not a consistent, scientific approach to estimating.
    – Chris Brettini
    Jan 27, 2020 at 10:30
  • Prove in a scientific way that only what is scientific correct is correct @ChrisBrettini.
    – Tiago Martins Peres
    Jan 27, 2020 at 11:31
  • And "not a consistent"... that's not true!
    – Tiago Martins Peres
    Jan 27, 2020 at 11:33

3 Answers 3

Reset to default
12

You can't be faulted for being confused. It is very common for organizations to try and directly match story points to a real-world measurement. This exactly defeats the purposed of using story points (and why I dislike Poker Planning for estimating).

A Story Point in simple terms is a number that tells the team how hard the story is. Hard could be related to complexity, Unknowns and effort. It was never intended to replace a time-based estimate. Instead agile (Scrum, XP, etc.) recognizes that time based estimating is flawed and avoids it. For example, a classic time-based estimate flow would look like this:

  1. An engineer thinks it will take him three days. So to be safe he says a week.
  2. Engineer's boss worries that it might be more complex or that there will be dependency delays so they pad out to two weeks.
  3. The Program Manager gets everyone's assessments and assuming engineers underestimate (hey, when was the last time a project shipped with all the original PRD items?) they add a 10% bugger to the schedule.
  4. Then, following standard project management best practice, the entire project gets assigned a 20% schedule buffer.
  5. Then senior management knows that executive management won't understand a best case/ worst case schedule, they just add the 20% buffer and make that the official release date.
  6. Lastly, Parkinson's law kicks in and the work expands to fit the available time. "Hey, we've got 12 whole months until we ship, we don't have to be code complete for nine months now!"

Story Point estimates work best when they are relational. You're not trying to estimate how much time it will take. Instead, you're trying to figure out if Story A is more or less complex than Story B.

Let's look at your example above:

  • Dig a 1m Hole: Well understood and no surprises. Team confidently gives calls it 3 points.
  • Dig 2m Hole: Roughly double the work of a 1m hole. Still well understood and no surprises. 5 points.
  • Catch an Elephant: Wow, we don't have any experience in this and that's going to require a lot of specialized equipment. Definitely more effort that digging a 2m hole. There is also a lot of unknowns in it so the team goes for a 13.
  • Because catching an Elephant is so new, they may even create a research "spike" to send someone off to research how to catch an elephant.
Improve this answer
7
  • 2
    So, let's assume, that we have three User Story. Easiest story we will estimate in 2 SP, a little bit harder story we will estimate in 3 SP and, finally, the hardest story will be 5 SP (next Fibonacci number after 3). But we fundamentally don't know what we will do more quickly: first and second story together or third story.
    – Sergey Kudryavtsev
    Jun 16, 2015 at 10:52
  • 2
    Despite the fact that these stories (1+2 vs 3) have equal sum of Story Points, implementing of first two and last story may take different time to us, because, in reality, we do not know value to which one story harder then another. We know only the fact that these three stories have different difficult. So, to compare or add with each other points is meaningless.
    – Sergey Kudryavtsev
    Jun 16, 2015 at 10:56
  • Did I understand you correctly?
    – Sergey Kudryavtsev
    Jun 16, 2015 at 10:56
  • 4
    Essentially yes. Remember, the purpose of estimating is to determine how much work the team can do in a sprint. This works out over the aggregate. In a good agile implementation you measure stories completed, not story points and you measure velocity variance, not velocity itself (velocity is an internal team measure). Feel free to ping me direct if you have more questions.
    – Joel Bancroft-Connors
    Jun 16, 2015 at 20:03
  • 1
    T-Shirt sizing is the gateway measure to estimating. People can get their hands around it very easily. A good choice. Even if you move to more detailed estimating for the team, in the future (which I do recommend), T-Shirt sizing is great for portfolio level planning.
    – Joel Bancroft-Connors
    Jun 17, 2015 at 15:33
6

As Joel saied, SPs are no real world mesaurement. They symbolize the necessary effort to complete a user story.

Because they are independent of a unit, they can be applied to everything that requires effort. Because of this loose definition, it's often advised to use the Fibonacci number to mark higher effort.

It helps me to imagine bottles of sweat created by the team necessary for story completion. Feel free to introduce a more convenient image :)

Improve this answer
1
-1

In my academic learnings I was always told to agree the customer charter first for change management reasons in accordance with PMBOK. Then look at the milestones and estimate these. These will help you decide how many sprints you need. Then you go an get the user stories. These form the product backlog where user stories are groomed and the user prioritises them. If these stories are outside the scope of the initial project charter then this is pointed out to the user and a compromise or agreement takes place. Does this help. I think that you may be hinting at change management. I apologise if I have misinterpreted the question. This is just a high level view of my implementation of Agile Project management. I believe that a good charter and plan are necessary first to see the successful completion of the software and a satisfied user. If you want me to expand any more I will be happy to do so

Improve this answer
1
  • 1
    If you're trying to fit agile into a larger waterfall process, this is commonly how it is done. It's also one of the leading places where we hear "scrum is failing." In agile, a product is done, when it has enough value for the customer. That could be after three sprints, it could be after twelve.
    – Joel Bancroft-Connors
    Jun 16, 2015 at 20:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.