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 and points showing up as dashes when estimate is put in story point field

sally1

I'm trying to figure out if this is a bug or I'm just doing the workflow incorrectly.

I have a current sprint and am adding stories since the team is finishing quicker than expected. The new stories don't have points (or 'estimate') yet. Someone then adds the points via an edit on the story itself instead of editing the 'estimate' on the planning board. The points then show up on the planning board under 'estimate' and all looks good but the points show up as a dash on the sprint report and never get added to velocity.

Even if I remove the blank pointed story out the sprint, add the points and drag it back in, it still keeps the points as a dash when viewing the sprint reoprt and they're not included in the final velocity tally.

Is that how it's supposed to work? Is my workflow wrong? Or are the fields not mapped in the database correctly? What is the reasoning for the dashes? Why don't those stories count?

Thanks.

Accepted answers

All comments

Alex

Hi Sally,

I think this is the intended functionality. The sprint report will only show you what the team actually committed to in the beginning of the sprint plan. If you would like to see all changes use the burndown chart.

Here is our technical documentation on the sprint report feature: https://confluence.atlassian.com/display/AGILE/Viewing+the+Sprint+Report

Let me know if you'd like to see a feature added to the sprint report which compares inital sprint plan and added scope column.

Hope this helps.

Thanks,
Alex

sally1

I get that logic, but that's not really how it's working because I can add a story to a current sprint that already has points and it gets included in the overall points (Otherwise, my 'completed' would never be higher than my 'committed'. If it doesn't count anything new, then if a team completed everything commited, the completed would never be more.). So it does allow for stories to be added. I think the issue here may be a bug.

I can add a story that gets the asteriks and gets includes the story points in the total. This increases my teams overall velocity and 'completed' story points.

But if I add a story with no points to a current sprint, then add the points, the team gets zero credit for that work. This seems like a bug to me. Why does it allow new stories that have points, but not allow new stories that get their points after being dragged in? I'm doing the same function (adding more stories after the sprint starts), but greenhopper is treating the way the points are added as completely different.

Does that make sense?

Alex

Hi Sally,

Yes, you can add stories with point values associated to active sprints, and the overall points will increase to reflect the additional scope, however, the committed scope does not change. Committed scope is the stories and their point values that were included when the Sprint Started. So if a story has a point value of 0 at the start of a sprint the committed scope for that issue is a story point value of 0.

The Sprint Report intentionally shows only the values for stories included in the committed scope. Issues that were not in the committed scope are included in the sprint report but their values are not. Additionally, if story point values for stories that were included in the committed scope change, this too will not be included in the sprint report. This is by design and not bug.

If you would like to see what was actually completed in a sprint, including stories added to the sprint, I'd suggest using the burndown chart.

https://confluence.atlassian.com/display/GH060/Viewing+the+Burndown+Chart

sally1

"you can add stories with point values associated to active sprints, and the overall points will increase to reflect the additional scope, however, the committed scope does not change."

--yep, completed agree. Committed should never change.

"So if a story has a point value of 0 at the start of a sprint the committed scope for that issue is a story point value of 0."

--Agree, committed should never change

"The Sprint Report intentionally shows only the values for stories included in the committed scope. Issues that were not in the committed scope are included in the sprint report but their values are not."

--Not my experience. Like I have said above, with an on-going sprint (days in to the sprint) I can drag in a new never before committed to story that has points already included and it gets added to the overall 'completed' number. But if I accidently or purposely add in a story that has no points, then add the points, it does not get added to the overall 'completed' number. If you could see my teams sprint reports, you will see stories that were added after the sprint started and their points show up and are included in the final totals and then there are others where there are no points. We pinpointed the issue to when the story points are added, not when the story itself was added.

"If you would like to see what was actually completed in a sprint, including stories added to the sprint, I'd suggest using the burndown chart."

--This doesn't total stuff up. You have to figure it out by hand. Not a good user experience.

"if story point values for stories that were included in the committed scope change, this too will not be included in the sprint report"

--What is the point of knowing your teams 'completed' velocity if it's never correct (and the sprint report ignores them)? Shouldn't the completed velocity show you everything you completed? How would a team ever be able to do any future planning if they don't have an accurate account of what they actually complete?

Alex

My apologies for this confusion. If I could restate your concern, it would be that when an issue's story point value changes (increases or decreases) after a sprint starts, the story point value associated with that issue disappears from the story point total calculation in the sprint report.

The expected functionality, therefore, is that the committed scope is captured in the sprint report, and changes to the committed scope are also captured in the sprint report, and that the total completed reflects the changed scope not the committed scope. Is this correct?

sally1

"when an issue's story point value changes (increases or decreases) after a sprint starts, the story point value associated with that issue disappears from the story point total calculation in the sprint report."

--No, not at all what I said. No points 'disappear' because I changed them. Like I said above, when adding stories to a current sprint, depending on how I add story points to those stories, they either do or don't get added to the overall velocity and sprint report. Nothing ever disappears. They are either there or they aren't. The reason the points show up or don't show up depend on HOW I drag them in to the current sprint. That is where my problem is. Greenhopper is counting the story points on new stories added to a current sprint and it counts them against velocity and the sprint report as long as they have their story points when dragged in. Greenhopper does not count the story points to a new story if the points get added after being dragged in to a current sprint. Basically since it was dragged in with null points, that's how greenhopper treats it. But the greenhopper how-to stats that it NEVER counts any new points, but as I keep saying and expirience in my day-to-day, it does count new points as long as I add the points correctly.

"The expected functionality, therefore, is that the committed scope is captured in the sprint report, and changes to the committed scope are also captured in the sprint report, and that the total completed reflects the changed scope not the committed scope. Is this correct?"

--Yes. Committed never changes. Completed should show up in the sprint report and completed velocity. Otherwise these two reports are inaccurate as they don't give a true respresentation of what the team completed during the sprint. You don't know what your true team velocity is over tiem and you never get a correct total from the sprint report.

Jonathan Stewar3

Was this bug ever raised as an issue to be fixed. We still don't get points added to the total completed points if we drag the story in mid-sprint.

I agree with sally in that if I add stories to a sprint after it has started, the story points for that story should be added to the sprint total when I complete the story.

sally has listed the workaround - add points before dragging into sprint.

Suggested fix: Sprint report takes the total completed points from all issues completed during the sprint when the sprint ends. Irrespective of whether the story was added pre-sprint or during sprint.

Also agree - The committed points should be set at start of sprint and be locked at that value.

Sloan Looney

I find this troubling as well. The purpose of the velocity chart is to see how the team's velocity is changing over the course of many sprints, not to see how close we got to completing our originally committed stories in a single sprint. We often make scope adjustments and add stories during the sprint as we are early in discovery and architecture for our product. In the most recent sprint 70% of our points went uncredited in the velocity chart, making it look like the team has fallen off a cliff productivity-wise.

I need the tool to reflect what I memorialized as "accomplished" from sprint to sprint. Perhaps what I'm looking for is a different report, but I find the current one less than useful except in ideal situations which I have never witnessed in real life. Maybe it's me.

Mark Kreider

I see this as a serious problem as well. Agile development is all about embrasing change. And, we need to know what our velocity is. Then you know what you should commit to, not the other way around.

Dipesh Parmar

I think my issue is related too - We set up a sprint in 'planning' containing the stories (zero story points) we think we will undertake. We then size the stories in a refinement meeting, and when we are happy with the number of stories, etc - we hit 'start sprint'. However the report shows all the stories as zero points - presumably the JIRA commitment is made when they are added to the sprint - not when the start button is pressed?

ccholette

This makes the velocity report and the sprint report pretty much useless for calculating historical velocity. We can see our variance from initial commit from the burndown chart.

Brian Bell_bkgxhp

Agree with comments above. The additional stories and points need to be shown in reports.

sdesalas

I find this very confusing too.

I expect the Sprint Report to show me how many points I completed in a sprint, plain and simple. Not how many points I would theoretically complete at the end of the sprint from an originally estimate when I pressed the "Start Sprint" button (who thought this was a good idea??).

I just forgot to estimate a story included in a sprint before starting it, now I'm stuck with a "-" (dash) in the estimate for that story whenever I look at the Sprint Report, and I have to tell the project manager that there is a bug in JIRA and we cannot estimate sprint velocity correctly using the Sprint Report.

This (as well as changing scope mid-sprint) happens way too often BTW.

I hear the Atlassian devs saying that "The report should only show the estimate at the begining of the sprint", but this sounds much like a cop-out to avoid fixing this problem.

UPDATE - June 2014

If you are an atlassian user, please vote for GHS-8776, which should hopefully resolve this and many related issues if and when Atlassian decide to show the actual amount of points (not the committed amounts) in its reporting functionality.

Philip Page

This is definately a bug. The behavior is different for stories added to the sprint after it is started and stories that start in the sprint withouth estimates and have estimates added later.

Staffan Solén

According to my experience, it is even worse than what you describe - It would be acceptable if the estimate was dependent on when you pressed the 'start sprint button', but it turns out that it is dependent on when you dragged an item to the sprint regardless of if you have started it or not! If you hadn't estimated the item before adding it to the sprint (in planning section), then you will end up with a 'dash' in the sprint report nevertheless...

Staffan Solén

My experience is that your statement 'Committed scope is the stories and their point values that were included when the Sprint Started.' is false. From what I have been able to deduce, it is the point value that were included when they were added to the sprint, not when the sprint started.

Correct?

sally1

I completely agree. We have the same issue about when a story gets added to a sprint. If it's not estimated before moving in to any sprint (started or not started), it caches that number, usually nothing, and the team won't get credit for it ever.

Lars S Broden

Atlassian folks, could we at least get an option (Push Button or similar on the scrum board) where we had the possbility to "Re-Baseline" the changed/added Original Estimate values in an ongoing sprint in the Sprint Burndown report. In this way the project/programs that strictly follows the "Committed Scope" doctrine for all their teams will have their default behaviour (as-is) and others could still get accurate Sprint burndown reports on added/changes estimates in an ongoing sprint

David Goldstein2

I agree with Lars' assessment above. Our SCRUM team is using the sprint report to sumarize all of the work that is completed at the end of the sprint. We use the number of story points that are completed in each sprint to determine the scope of subsequent sprints. Without having an accurate count of the number of story points actually completed in a sprint we do not know how to evaluate the team's performance sprint to sprint. The burndown chart does not provide this information.

Stefani Ribaudo

I am now forced to create reports on my own and not use JIRA reports. One of my arguements for purchasing JIRA in the first place was the excellent reporting functionality. The executives of my company are not happy with JIRA for a few other reasons and now that the reporting does not make sense they are talking about moving over to Rally. Can somone from Atlassian respond to the concerns in this thread please?

Ronny Hanssen2

I have done some tests on this and can somewhat conclude as follows:

1. The commitment initially seems fine to me. It calculates the amount of SP when the sprint starts, as expected. But, I also do have a feeling that there scenarios where there are issues. When a story have been in more than one sprintI think perhaps it uses the SP as they were when the first sprint started. Or - if you change estimation method between the sprints.

2. The velocity seems to include SP as it ws at the time of the commitment. If the SP estimation changes, or if you add other issues they are not included in the velocity. I can hear the "purists" say that this is as it should be. However, I think there are many (like myself) who would like to calculate the velocity based on *actual* SPs completed. BTW: I also think that the velocity calculation can suffer from the same problem as mentioned above with issues that lives through two different estimation statistics methods.

I really hope that Atlassian can adjust these, as the velocity is way off for us know. It claims 20, when the real number is 46.

sdesalas

GHS-8776 - As a Scrum Master, I want the story points completed to also include added in user stories that were completed in the Sprint and Velocity Reports and not just committed user story points.

Mo Berry

I just want to point out that the Burndown chart is miscalculating points in the same way as the Sprint Report. With scrum teams can "Commit" to take on additional points mid-sprint. There should be Planned, Committed and Accepted. Planned would remain the same. Committed and Accepted will change over time, until the Demo. The fact that we cannot trust the out of the box Sprint Report and Burndown chart makes managing a an agile team more difficult and time consuming.

Antoni Maciasze

@Alexandra Kassab have any changes been made since last discussion 3 years ago. I still have this problem with real/predicted points on Sprint Report.

I consider team velocity what ammount of work was actually made not wrongly predicted...

Can you please point some solution for this?

Kaminski Wojciech

Completely agree with you. Especially for the beginner , the beginners make the mistakes by added US after started sprint and after it is impossible to correct this errors. It is a BIG PITY that Atlassian Team can't imagie to give possibility to correct that mistakes

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

scrum

sprint

retrospective