Correct estimate of story points not appearing in sprint report

[ashleyg]

Suppose we create a sprint and associate few user stories with estimated story points to this sprint.

Now we start the sprint and once started we change the number of story points in the issue which also get reflected in th eboard. But in sprint report generation it still shows the story points as estimated in the initial of the issue before start of sprint.

PLease let me know how to overcome this Jira bug.

[Tom Baker]

No. This is stupid. THIS IS A BUG!

If you don't want to fix it, at least change the label to say "Initial Story Points" so that it's clear what data is ACTUALLY being displayed.

[pablo macouzet]

This is either a bug or bad design. The reality is that LOE on stories can definitely change. Please make this more flexible.

[juliette.mount]

Absolutely. Please fix this. It's making this report useless.

[Eoin Jordan]

This seems to be inconsistent - if it is possible to edit the story points within a sprint then why shouldn't they be reflected in the reporting?

Editing story points has nothing to do with sprint duration.

If I have made a mistake with the approach to estimation in my first sprint then without correction I am either stuck with adopting an incorrect estimation system for the remainder of the project or stuck with less than useful JIRA reporting which has inconsistencies across sprints.

Eoin

[Nitin Khanna]

I'm looking for a solution or work-around for this.

I appreciate that @Elisa Diel [Atlassian] has quoted directly from the 2013 Scrum Guide, as authored by Sutherland and Schwaber – the co-founders of Scrum.

However, the quote is misplaced and the misunderstood. What has been written is on is reinforcing the importance of the timebox.

Further, Scrum does not stipulate how to do estimation. I have worked with teams that have used no estimates, as well as teams that do. For those who do (currently), our Team wold like to see all work declared done, along with a sum total of points. This is currently not visible in the out of box report.

If anyone has a solution, please share. This could be an add-on, etc.

[Elisa [Atlassian]]

Hi Ashley,

This is an expected behavior. The documentation says:

The values for each issue's Estimate are recorded at the time the sprint is started. Changing the Estimate value afterwards will not be reflected in the Sprint Report. If an issue was added after the sprint was started, then the estimate is recorded at the time it was added to the sprint.

That is because according to Scrum:

Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened. The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process.

Please, let us know if this answers your question.

Cheers!

[Zoe Feltham]

Hi @Elisa Diel [Atlassian] This is really restrictive. I do understand that in scrum you shouldn't edit the scope of a sprint during the iteration, but in reality there are situations when you have to do this. To give a couple of examples: - If business priorities change mid-sprint a Product Owner may pull stories out of the sprint and replace them with stories which are aligned to the new business priorities (this is not ideal, but it happens) - If developers get through all the stories more quickly than expected and pull in new stories from the backlog which have not yet been pointed. - If a story is pulled in which is subsequently broken down into smaller stories. I understand that it's useful to understand what has been committed to initially, but we also need to accept that we live in the real world, and I have never met a product manager who would claim that they follow a 100% perfect scrum process 100% of the time. Why should our reporting have to suffer in the scenarios I've described above? I'd suggest updating the reporting to show: 1. What was committed to at the beginning of the sprint 2. Points added and removed during the sprint 3. Total number of points completed from the committed stories 4. Total number of points completed overall (including stories where the scope has changed and stories added mid-iteration) There's a ticket been raised about this which has 120 votes and lots of comments (https://jira.atlassian.com/browse/GHS-8776) but it was raised over a year ago and no-one from Atlassian has ever even commented on it. Please could this be escalated to be reviewed, as it's incredibly frustrating not being able to properly track my team's velocity because of an arbitrary decision by Atlassian. Thanks Zoe

[T B]

I strongly agree with Zoe.

[Dawn Cain]

This report is ignoring actual data in support of a rule in SCRUM. If Atlassian wants to adhere to the SCRUM rule, then it would be REALLY helpful to show what the deviation from the "Original Estimate" was, vs. reporting incorrect final numbers for the sprint report. If we, as a team, have documented in Jira that we changed our sprint, then we should see that change on the report. Especially since a change to the sprint, per SCRUM rules, would signify an issue with my team's adoption of SCRUM. Simply writing the report to ignore the data makes the report useless, and incorrect. The data is not reflecting what was done, and it also doesn't tell me that my team deviated from the plan.

[juliette.mount]

The sprint length is fixed. That's the time block, not the effort.

Points allocated to a Story can change based on additional insight. The value changes, so when completed, this should be reflected. Often, for example, an urgent change is required and must be accommodated, so you bring in a 3 point issue and remove a 3 point issue. This should be equal, but JIRA penalizes you for removing the original issue, and doesn't give credit for the replacement. So, it's not accurately reporting the work, and if you think that this doesn't happen in real life, and us e done, you're missing a whole group of user stories in your development efforts.

[Tim Thompson]

I would like to be able to identify three types of story point values:

1. Original estimate in backlog (probably done by an individual to get funding)
2. Team commitment at time of sprint planning/start - planning poker and all that. 
3. Actual at time of issue closed for velocity - which allows for changes/decomposition/splitting during the sprint if necessary. 
   
   

It looks like JIRA stores 2&3, but cannot select for different views. I've been creating custom fields so I can do analysis on backlog accuracy and team estimating - but need to download to excel to play. 

[Endlé Christophe]

I have a solution

Do not use sprint-report to count UPS but instead, use the button "in Vorgangsnavigator Anzeigen"

I am able there to find my 113 UPS Done instead of 98 UPS as display (Excel export helps ...)

Jira-issue.pngI ka