Plot story points vs logged hours

Is there a way to plot the logged hours vs the story points per issue?

We are looking for way to have a feedback on the extimations in story points, something to answer the question: Were the extimations aproximately rights?

Find out which stories have been wrong extimated, find out the reason of the wrong extimation and do better extimation in the future.

4 answers

1 accepted

I find extremly irritating receiving spam emails from atlassian, that I have to close this question although nobody has given a useful answer yet. I find this system completly useless and I will go through the support, I suggest anybody to not use this "answer" forums, it's just a waste of time.

Renjith Pillai Community Champion Nov 13, 2013

Dont be that rude my friend :(.

Answers do help people out there. Since this forum is totally voluntary not every request might not get answered.

Hi ASE Admin,

Although we should avoid as much as possible linking hours to story points, there are times where this can become useful. One such case is when we want to monitor the health of our estimation process. Based on this, we can effectively correct bad estimation practices.

There is an add-on on the Atlassian MarketPlace called Rekall which does this. Rekall allows you to use triangulation to estimate your issues but it also offers a Statistic Board which plots the Story Points estimation per logged hours and give you its statistical distribution. From there you can see if your estimations are fairly linear over all the story points. You can even remove outliers data points.

Hope that helps and that it makes you change your mind about Answers. It really is a nice place to find answers to most of your questions.

Yves

2 votes
Renjith Pillai Community Champion Nov 05, 2013

That's totally a bad idea. Trying to map story points to hours breaks the whole idea of story points. Just my opinion.

http://scrum.jeffsutherland.com/2010/04/story-points-why-are-they-better-than.html

http://www.mountaingoatsoftware.com/blog/how-do-story-points-relate-to-hours

@Renjith

Nope, story points are to better extimate the stories, but can you explain what is the velocity? Perhaps story points per sprint = story points / weeks = story points / hours ? Isn't it?

Why do you calculate the velocity in the first place? Because it's sound cool? Because scrum says that you have to do it? No, you calculate it because you have to plan and you have to know how much time it takes to complete something.

For example if you have 600 story points to do and your team can do 200 story points per sprint, one sprint is two weeks long, you need about 3 sprints to do 600 story points, this means 6 weeks.

The idea of plot story points vs logged hours is to find out the tasks that we though were simples and then they have taken a lot of time. So we can investigate these tasks and find out the resons of the underestimation and next time make a better estimations.

This is just a feedback loop, what also scrum suggest to do in the retrospective.

And last but not least I would like to citate the Jeff's article, that you have postd the link:

"The important metric is the number of story points the team can deliver per unit of calendar time. The points per sprint is the velocity. Therefore we estimate everything in points for the Product Owner so that he create a release roadmap based on team velocity and adjust the plan if velocity changes."

1 vote
Renjith Pillai Community Champion Nov 13, 2013
  • Velocity is the number of story points completed in a sprint
  • The calculation you mentioned exactly is the release planning process which is achieved in the version charts in GreenHopper

Regarding this comment:

The idea of plot story points vs logged hours is to find out the tasks that we though were simples and then they have taken a lot of time. So we can investigate these tasks and find out the resons of the underestimation and next time make a better estimations

This is the not really based on story points. It is purely based on the technical task estimation done by the team during sprint planning and it is a subject of discussion in the retrospective meetings for the team as your correctly mentioned. After all it is the team who has to find ways to improve the estimation. And take it from me, it will be bad the initial sprints and it is expected it to be that way.

Remember story points cannot be compared to effort estimates. It is a collection of all factors. It automatically takes care of the conditions in which the work happens, the competency of the teams, all other wastages that happen during development, all resource crunch that happens for testing and continous integration, all release related efforts. It is completely a relative value which makes sense only for that context.

I was researching for some time for some links to share. Didn't find an exact match, but a couple of close ones

http://rationalgeek.com/blog/story-points-whats-the-point/

http://www.axisagile.com/blog/estimation/relative-estimation-communication/

http://agileyammering.com/2013/07/17/analogy-scaling/

Suggest an answer

Log in or Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

3,336 views 14 20
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot