Plot story points vs logged hours

[admin ase]

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.

[admin ase · Accepted solution]

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]

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.

[Yves Riel [Okapya]]

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

[George Mihailoff]

For those who are still looking for insights, our app Quantify Agile can do this. We also solve a very tricky part -- the actual spent time -- in a way that teams don't need to manually track time.

[admin ase]

@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."

[Renjith Pillai]

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 Pillai]

• 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/