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.
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.
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.
That's totally a bad idea. Trying to map story points to hours breaks the whole idea of story points. Just my opinion.
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."
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
I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...
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!
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