Estimating story points

[Alex_Fyfe]

Hi all,

I've just watched one of the training videos and don't really understand estimating story points as to me all they do is set a priority against a task and don't let you know how long task will take thus how can you plan a sprint??

For example, if the team estimate a particular issue and state it's 8 story points I'd think that was a high priority but it doesn't tell me whether the task will take 1,2 or 6 days.

Kind Regards,

Alex.

[Mohamed Benziane · Accepted solution]

Hello @Alex_Fyfe 

You can take a look at this article

https://www.atlassian.com/agile/project-management/estimation

 and this one too

https://www.scrum.org/resources/blog/why-do-we-use-story-points-estimating

[Alex_Fyfe]

Hello @Mohamed Benziane 

Thank you for your response.

Having read through the two links my understanding of story points is:

Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work. This is based on:

• The amount of work to do
• The complexity of the work
• Any risk or uncertainty in doing the work

Story points differ from estimating in hours as it takes in additional work such as meetings/sending emails etc.

Two issues.

• I've used Jira in a couple of companies for software projects and never seen story points used only time estimates.
• If you're not using story points then reporting say with a burnup chart is of no real use.

I'd be interested to understand your opinion on this.

Kind Regards,

Alex.

[Mohamed Benziane]

For the second point, you can indeed use the burnup chart even you are not using story point.

The documentation says:

Understanding the Burnup Chart

• The vertical axis represents the amount of work and can be measured in different ways such as story points, issue count, or estimates. The horizontal axis represents time in days.
  
• The distance between the lines on the chart is the amount of work remaining. When the project has been completed, the lines will meet.
• Examine the 'Work scope' line to identify any scope creep.

For the rest, I completely agree with you.

I will just add that to really understand the value of a story point the first sprint will be decisive you will be able to know the velocity of your team and how much issue you can take in a sprint.

[Alex_Fyfe]

Hello @Mohamed Benziane 

Thank you for the clarification.

Kind Regards,

Alex Fyfe

[Tosha Liveoak]

Hi, 

@Mohamed Benziane I am still so confused about where to even start with estimation and using story points.  I've read this and other info.  I am the PM for our team and we use cloud Jira tools including JS.   I have roughly 7 months of experience using it. I'm working to get a better grasp on resource capacity.   So after several hours of learning Advance Roadmaps in Jira, I'm stuck on using story points and estimation.  I have not introduced this to my team yet and we've been working in hours/days/weeks.  I need to understand it before I can use it and present it. 

Any suggestions or conversations I can have?  We are a premium support user.  Thanks!

[Lex Kovalenko _Appfire_]

Hi @Tosha Liveoak 

Maybe this article can help a bit: https://hub.appfire.com/popular-topics/software-development-and-devops/story-points-friend-or-foe/ 

I'm also available for a chat if you have any questions. But I'll also have questions to help my Jira usage research. 

[Tosha Liveoak]

Thank you @Lex Kovalenko _Appfire_ !  I will take a look and let you know!

[Tosha Liveoak]

Great article @Lex Kovalenko _Appfire_ ! TY for sharing!  

So, essentially Story Points should be estimated in "ideal days".  However, I'm not understanding "load factor" and the multiplication resulting nine days to complete from the section in your article below:

As Ron Jeffries describes, the original “Points” for estimating “Story” were based on “Ideal Days” to finish a specific PBI. These could be converted to work days by multiplying by the “load factor.” This would give you the actual implementation time.

For example, a story estimated as three “Ideal Days’ multiplied by a load factor of three yields an estimate of nine days.

But stakeholders were confused with three ideal days estimation versus nine non-ideal days, so Ron’s team started calling “Ideal Days” “Points” or “Story Points.”

And that’s how the Story Point concept came to be—time estimation, that evolved into a different, very popular estimation tactic.

[Lex Kovalenko _Appfire_]

Hi @Tosha Liveoak 

I'd say that you shouldn't think of the ideal days and the load factor, it's just for your understanding of the concept behind SP.

If I were you, I'd ask myself if I and my team are good at time estimates. If no, then go ahead and try SP, we have no better alternatives.