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.
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.
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.
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
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.
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.
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.
I would like to be able to identify three types of story point values:
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.
Not one, but two f***ing legends busting myths about passwords and user management. From left to right: Christian Reichert and Björn Döhler from re:solution going on a grand tour. Video here: h...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events