Skip to main content

How to handle stories in a sprint that are no longer applicable

Last post 05:42 pm September 26, 2019 by Adam Smyth
4 replies
04:20 pm September 25, 2019

Hi,

My team currently have two testing stories in their active sprint that are no longer valid due to the work being done by another team. 

  • Do we delete the story completely from the backlog removing it from the sprint as well?
  • Do we change the value of the story to zero and close it out in the sprint adding a comment to say why this has been done? To me this means there is no value to it seeing as no work was started or completed so the burndown doesn't record story points for something the team never delivered.
  • Or is there an alternative?

We are using JIRA.

Thanks.


05:08 pm September 25, 2019

What is it that you try to achieve here? If it is not Done at the end of the sprint, and obsolete, simply delete the story.

If you want to keep track of storypoints, you can use the "Cancelled" state in Jira, which will count points towards velocity and charts.


05:16 pm September 25, 2019

It depends on your processes.

Personally, I prefer to never delete issues in Jira. There's a resolution of "won't do" or "won't fix" that can be applied. As far as changing the value of the points, I don't know that it matters so much. Jira calculates the "committed points" when you start the Sprint and reducing the points to 0 or moving the work out of the Sprint or closing the issue would all show up on the generated Burndown Chart. Therefore, you should do what makes sense for your team.

However, I would want to understand how something went from the backlog, through refinement, into Sprint Planning, and into a Sprint before realizing that the work was done or being done by another team. It seems very inefficient to plan on doing work to have it become obsolete.


05:27 pm September 25, 2019

My team currently have two testing stories in their active sprint that are no longer valid due to the work being done by another team. 

What is a testing story, and why would testing work be done by another team?


01:51 pm September 26, 2019

Thank you for your replies. I was trying to be vague in my reason for this so not to reveal any company information. This reason was just used as a way to provide background to what I want to with those stories. The stories were planned and were necessary at the time of bringing them into the sprint. During the sprint we discovered that the testing could not be completed as expected. The time to perform the testing has passed so it cannot be dropped into the next sprint. 

My thinking is, as the team did not perform the testing we should not get 'credit' for it by closing the story with the original story points. Reasons for why the testing could not be done have been documented in the story and I believe they need to be kept for compliance reasons. So, to keep the story, but not mark it as done, my thinking was to value it as zero and close it without marking it as 'Done', or apply another status to the story that would accurately reflect this i.e. use the 'cancelled' state as Xander suggested.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.