nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Sprint Report 'completed story points' figures not taking into consideration updates to story point

Tom Lim

We're using Jira and Greenhopper on demand.

We're tracking with 'story points' for our sprints.

We noticed that the 'Done' story points on the Plan board don't match up with the completed story points on the Sprint Report. This same 'completed' figure rolls from the Sprint Report into the Velocity report. The Plan board figure is higher than the report figures.

After some investigation and manual calculations, we discovered that the Sprint Report does not take into consideration updated story points while the sprint is in flight. I.E. when tasks are added to the sprint (we do this to record blockers for stories and raise them as a defect) and when story points are reevaluated and increased.

So if a story with story point 3 is evaluated to be more complex and upagraded to 5 story points. When we resolve the story, the original value of 3 is recored in the sprint report instead of 5.

The Plan board has (what we consider) the more correct figure. However we lose this once the sprint is completed.

Is there a way for the Sprint/Velocity reports to take into consideration these changes?

We consider our velocity calculations to be incorrect if it doesn't take int account these slight increases.

Accepted answers

Renjith Pillai

It is by design. The whole aim of velocity and story point estimation is to get a 'guesstimate' of what the quantum of the work and to retrospect on the estimate and make it better every time. The values during the entry of the sprint is taken for the velocity calculation and IMHO it is a wrong practice to change the story points during a sprint.

Also if the team realizes that it is a wrong estimation, it is fine, leave it and get the estimates better next time. If the story get carried over to next sprint, you can any do reestimate.

Some links which I got from Google.

http://www.mountaingoatsoftware.com/blog/to-re-estimate-or-not-that-is-the-question

http://programmers.stackexchange.com/questions/154465/scrum-how-to-carry-over-a-partially-complete-user-story-to-the-next-sprint-wit

All comments

Renjith Pillai

Also if the team realizes that it is a wrong estimation, it is fine, leave it and get the estimates better next time. If the story get carried over to next sprint, you can any do reestimate.

Some links which I got from Google.

http://www.mountaingoatsoftware.com/blog/to-re-estimate-or-not-that-is-the-question

http://programmers.stackexchange.com/questions/154465/scrum-how-to-carry-over-a-partially-complete-user-story-to-the-next-sprint-wit

Tom Lim

Thanks for the reply.

The team is new to Agile.

I do like how they are identifying that their initial estimates were wrong. This will only help them get better at estimating for future sprints. At this point in time I don't want to discourage them too much.

The velocity is reported back to management, so we do want to get it as correct as possible as decisions are made around these metrics.

Renjith Pillai

And keep reminding management that the velocity values is only to determine an actual trend of the project progress which can stabilize after a couple of sprints and do not use that value for any team level decisions as it is purely relative. Any decisions based on team performance made on those values is to complete de-stabilize that and teams will starts estimating high values just to ensure their metrics look right and your project planning will go wrong.

sumtraveller

I don't understand why we would ignore newer, better information for older, worse. Given that Jira/GH doesn't allow capacity planning, the best that we can do is have an accurate measure of our velocity.

So consider, we recently had a story that we thought was 21 story points. After getting into it, the developer figured out a 2 point way to solve the problem. We reestimated the story to better reflect the size of the effort.

Given that software development is always trying new things, this happens A LOT. I would really like the option of having a more accurate estimate of our velocity.

If people want it the other way, fine, but give us the option.

Danny Gershman2

I agree. In some cases we added stories to the sprint and didn't get a chance to estimate them until a day or so later. It should just allow you as a user to decide how you want to use the product. Not make assumptions on how you want it to work.

Paul Davidson

It is not up to Atlassian to tell us how to do scrum. We often re-story point at review or add stories to a sprint as pullins. This makes the report useless.

Bruno Juchli1

Last sprint we undercommitted. So when we'd done all our committed work, we got together and did some more sprint planning and added some more work to the sprint. We estimated the story before moving it into the sprint. However, we didn't enter the story point value at JIRA before moving it into the sprint. So "reality" and how we instructed JIRA about the "reality" differed.

Now i`m stuck with a sprint with incorrect velocity. It's totally NOT okay that there is no way to correct honest mistakes like that.

Since i`m quite new to JIRA Agile i've made other similar issues. For one, at the beginning i did not care about versions. So i didn't assign any versions to the story items. Few sprints later i found out that i can assign versions to track and forecast release.
Now "version report" and "release burndown" - although technically very cool features - are totally dead to me. No relevant info can be displayed.
Of course i could settle to do it right from now on. But that would basically lose velocity and other information from before. Also, i could not show the progress of the release in it's entirety, just from sprint X on.

At the end of the day, all reporting functionality of JIRA Agile is unfit for actual use. It's a total over-promise since in every day usage you'll end up with invalid data.

Bottom line: I feel defrauded, cheated, swindled.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-software-cloud