Story points counted twice in two sprints

[Savy]

Hello,

if a ticket gets carried over to a second sprint (or gets pulled from a sprint and added to another later), its story points get counted toward both sprints. This skews up the actual percentage complete of a past sprint. Is there a way to prevent this and display the actual completed tickets within a sprint at the time of closing the sprint and any rolled over tickets that are completed in subsequent sprints to show up only in the sprint it was actually completed and not in sprints the ticket was a part of at any point in time. 

I am using this information in the Rich Filter statistic gadget on my dashboard and is an annoyance to see the percentage of a completed sprint keep going up.

[Hung Nguyen]

I experienced the same thing with Rich Filter gadget which will count double when a story spans across 2 sprints or more. I couldn't have a nice solution to solve this, since it's the way the sprint field had.

The work around for this is to create a custom field named Last Sprint and copy the Sprint name or sprint id into the Last Sprint every time the  Sprint field changes for a Story.

Then use this Last Field in the Rich Filter gadget.

[Savy]

Thank you, Hung. This is a good work around but our product team is not in favor of creating custom fields.

[Priyanka Yadav]

@Savy 

For your query, there are 2 cases

1. The story that is moved from one sprint to another without any progress then the complete story point should be considered in the next sprint.

2. The story that is moved from one sprint to another with some work completed on it then while planning you should update the story point (reduce the points which is completed in previous sprint)

The above scenario will be helpful when you do not know that the story will get spilled over.

If during planning team highlights that the story is big and cannot be completed in one sprint then during planning/grooming this should be broken in 2 story before adding to sprints.

[Savy]

Thank you, Priyanka. I agree with both of the scenarios that you have mentioned but in our situation, since we interact with external systems, we have a huge dependency and stories tend to roll over. In one of my dashboard, I have created two gadgets - one to track planned story points and one to track completed story points. Here I get the right count of story points. The issue occurs only when I use the Rich filter statistic gadget where stories that are part of multiple sprints get counted in all those sprints. The other option I am considering is to move the not-completed tickets to the next sprint before closing the sprint.

I would love to use flow metrics but our organization is still maturing in agile methodologies.

[Joseph Chung Yin]

@Savy 

Welcome to the community.  If an issue is moved from one sprint to another sprint, then it will not cause the issue (unless the sprint it is moving from is already in progress).  The only issue you will see is the initial committed pts for the sprint.

As with the Rich Filter statistic gadget, it is a third party add-on provided you with the functionality.  If that was the case, then you need to follow-up with the vendor of the add-on for further troubleshooting.

Sorry.

Best, Joseph Chung Yin

[Savy]

Hi Joseph, I think this is an issue with Jira itself and not Rich Filters. If Jira can some how make the Sprint field a single-value field and house only the active sprint the issue is part of and move the completed sprint values to a different field, we may not be having this issue.

[Aaron Morris]

Hi @Savy - In what way are your past sprint metrics being skewed? Changes to the story after the sprint is closed typically do not impact the metrics of the closed sprint. (Sprint metrics are usually locked (snapshotted) at the beginning and end of the sprint.)

Edit: Never mind. I see you're talking about a dashboard gadget rather than the sprint report (etc.). 

In the case of a partially completed story that carries over, you may want to try splitting the story at the end of the sprint so that the completed part stays in the first sprint and the incomplete part is a new story for the next sprint. That should help the gadget work better.

I'm unsure how to help the scenario where a story is removed from one sprint and added to the next. If the gadget insists on still including it in the first sprint, then maybe that can't be helped.

[Savy]

Hi Aaron, we follow the process of either the story is done or not done. If it is not in the Done status, then they move to the next sprint. Splitting it will then make it a mini-waterfall approach.

The other option I am considering is to move the not-completed tickets to the next sprint before closing the sprint.