Best practice for a story that team decide won't now be started in sprint (Server 7.4)

[Matt Stephens]

Hi all,

Looking for some best practice advice here - in particular to make sure we are making the most of JIRA reporting etc.  We're on JIRA Software Server 7.4.

I am pretty clear that if a story has been started but doesn't get completed in a Sprint, I should leave the story in the sprint and when I close, JIRA notes that in the sprint report and takes the story back to backlog.  That all sounds correct to me.

However, I have a situation that we are part way through the sprint and there's a story that hasn't been started yet, which the team feel won't be picked up in the sprint (eg: won't even be started).  There is an opinion here that the story should now be removed from the sprint so the team are maintaining focus on the work they actually can deliver.  I see some merit in that, but at the same time it feels like it's more correct to leave it in and show in the sprint report that we planned xx points, and that story was one that didn't get delivered.  Otherwise maybe we'll be seeing an artificial view of what the team are planning vs delivering, what our true velocity is etc?

What are people's views on best practice on this please?  Does it make any difference to how JIRA reports the sprint afterwards?  eg: if some stories were started but didn't complete, and some were manually removed from the sprint.

[Tarun Sapra · Accepted solution]

Hello @Matt Stephens

You should not remove stories from the Sprint because incomplete stories at the end of the sprint are very helpful in revealing lot of cracks in the team-work thus big scope of improvement.

In JIRA in "velocity chart" you can easily see the committed vs completed points. If the team continuously overestimates at the time of sprint planning or under-delivers over a period of 3-4 sprints then the whole team has to sit together and see what is going wrong. I have seen teams spending large chunk of sprint time in fixing broken builds due to poor automation testing and bad unit tests thus uncompleted stories are helpful in revealing where exactly the team is going wrong because it was the team only which incorporated the stories during sprint planning and now they are unable to complete them.

I hope this helps.

[Matt Stephens]

Hi @Tarun Sapra.  It does, and I think this is my opinion also, but I have a difference of opinion in my organisation so need to be able to clearly articulate the benefit to influence this. 

Someone here has told me that you can't mark a sprint as complete with open stories, but I thought JIRA handles that and moves items back to backlog for you when you complete the sprint?

If I do manually remove stories from the sprint, does JIRA still see them as part of the original scope and just not delivered in the sprint?  In which case actually either approach works?  And it's just how you present / discuss the information in review and retros?

[Tarun Sapra]

Hello @Matt Stephens

When you close a sprint with incomplete stories then JIRA moves them to next planned sprint or backlog but at the same time those incomplete stories are visible in the sprint statistics like Sprint report and Velocity report hence you don't need to manually remove them from sprint.  

During the sprint retrospective the team can discuss the information in the sprint reports and find a way to avoid having uncompleted stories at the end of  every sprint as occasionally having uncompleted stories at the end of sprint is fine but not every sprint.  

[Matt Stephens]

@Tarun Sapra understood.  But if I DO manually remove, does JIRA still include in those stats and reports?  Is there actually any difference between manually removing or JIRA doing it for you?

The reason I'm asking this is I'm getting pressure to remove the stories to ensure no-one accidentally starts working on one (we have a distributed, multi timezone team so this is a genuine risk) and to ensure everyone is more focussed on delivery of the now planned work...

However, I'd still like to be able to use the stats and reports for retro...

[Walter Buggenhout]

Hi @Matt Stephens,

This is more a discussion about practice than just about the tool. But a few of my thoughts on this:

• Keeping the story in or removing it does not affect what you call your 'true velocity'. Velocity is the number of issue types completed in a sprint. No more, no less. Your original commitment is nice to know, but mainly for reference.
• When you remove a story from a sprint, this will be recorded in your sprint report. So you will be able to see afterwards that an issue was removed from the sprint.
• If you are very strict regarding the original scope you committed, you should keep the story in your sprint. But if you look at it more pragmatically, you want to avoid someone picks up the story when it's not intended to be developed.
• Regarding my previous point - it might depend WHY the story shouldn't be picked up. Is another story more important? Will it not be developed al all? Anything else? Evaluate the reason and take appropriate action (reprioritise, close the issue as won't fix, ...)

[Matt Stephens]

Thanks @Walter Buggenhout.  Velocity yes of course makes sense, was just wondering if JIRA did anything with 'original scope' vs 'actual' or something like that.

As long as JIRA can show me that a story was removed (as opposed to a partially completed story that didn't get completed by end of sprint) then that covers what I need I think.

It's the pragmatism of real life I think that's going on - it's simply neater on the board to remove stories that were originally planned but the team now genuinely believes there is no chance will be done.  In our case it's because some other work has taken longer and we don't now have capacity.  

[Walter Buggenhout]

I just created a sample report in Jira Cloud for you based on (really basic) sample data:

As you can see, issues removed from sprint are clearly listed in the report. Just to make that point visible.

But coming back to my previous point on the reason why the team would like to remove a story from the sprint; not having enough capacity to complete is not a good reason to remove it. I second @Tarun Sapra on this - it is the team's responsibility to get a good grip on what it commits to. 

[Matt Stephens]

Thanks @Walter Buggenhout and @Tarun Sapra for both responses.  I do agree with the principle and funnily enough when I asked the team their opinion they also want to keep the stories in for exactly the reason that it's what they planned.  It's actually the SM (who is now PO!) I've taken over from who suggested we should take out!  So we're leaving them in as that's the dev team decision :)

Thanks for the example report that's super useful - I can see we will clearly be able to see that some stories didn't complete but were in progress/in qa/etc vs some that didn't complete and were still 'to do'.  That's exactly the view I want and we can use to discuss what happened.