I’m frequently asked the question:
If a team wants to maintain stories that are deemed unnecessary, what is the best way to show these in Jira versus having a resolution status of "cancelled".
My view is to move issues to a Done status (any status with a Status Category of “Done”) and update the resolution field with a resolution of "Won't Do". "Won't Do" is a resolution indicating we are done with an issue because we've decided not to do it.
If you click on the question mark next to the resolution field, you'll be taken to a pop-up help page that displays the configuration of the Resolutions for your Jira instance.
This question mark is actually deep linked to the Resolutions heading on a special Issue Concepts help page. This page provides users with additional information about resolutions, statuses, and issue types (et. al.) without requiring them to have admin rights.
Sometimes a feature will be removed from scope by the product owner in the backlog. In this case I recommend they set the resolution to Cancelled.
The description of the Resolution is very helpful and important here. You don't want shrug your shoulders if people ask, "Why would we use this resolution rather than that resolution?"
Always keep the names and descriptions of your Resolution clear and meaningful. I regularly review requests for new Resolutions because my Jira teams sometimes ask for a Resolution without realizing (or caring) that they are global. It’s important to not pile on a large number of Resolutions because:
If a story makes it up to a current sprint and is then considered Done, with a resolution of Won't Do or Cancelled, its points will count towards the velocity for that sprint.
This isn’t a big deal if tasks, bugs and other issue types are not story point estimated. I never require my teams to provide story point estimates for tasks or bugs. In fact I only require story point estimates for... well, stories. By only providing story point estimates for stories, I keep the velocity cleanly focused on work that delivers customer facing value. For non-story issues, using a Resolution of Won't Do or Cancelled will not affect the velocity in any way.
For story point estimated issues in the current sprint, I prefer teams remove the item from the current sprint, returning it back to the backlog, first. This will de-scope the item from the current sprint, prior to marking it Won't Do or Cancelled.
I prefer that teams de-scope these items first. This is because the team has already erroneously committed to doing the work by placing it into an active sprint in the first place. An issue never should have made it to the current sprint if it wasn't really required and/or needed. This reinforces the idea that proactively planning and committing to the work in each sprint is the best way to minimize the use of the Resolutions of Cancelled and Won't Do during a sprint.
To put it another way, this reinforces the team's responsibility when making a sprint velocity commitment and should encourage them to conclude:
We, the team, let this get into the active sprint to begin with. We should remove the story points from our velocity for this sprint and do a better job making sure we are all really committed to the work in each sprint we are about to start.
Sometimes teams get upset when I enforce this as "My Product Owner should have cancelled it" before it even got to the sprint or "The developers decided we didn’t need it” after the sprint started. When I hear this concern, I gently remind the team that Velocity is not a Key Performance Indicator, it's a measure of how many valuable features points were able to get done in an iteration. So the reduction of their velocity is a reflection of what the team committed to that they, to be blunt, shouldn't have. It's about the team, and it's not really important whose specific fault it was.
The team can improve its planning and elaboration process to drastically reduce the likelihood of this happening again. If this happens again, sure you’ll take a velocity hit, but your Velocity will remain an accurate reflection of how many customer facing valuable stories were delivered during the sprint. That’s all Velocity is meant to be.
For more on this topic, also check out this post: Jira Workflow Resolutions: Resolved, Closed, or Done?