what to do with out of scope tickets in JIRA

Question

I've created a number of tickets (user stories) and added them to the backlog, however on review the stories are now deemed out of scope.

What is the best practice for handling these? Should they be deleted? remain in the backlog perhaps with a different status "out of scope" perhaps?

Answer 1

Let's pretend you had a physical card wall for a moment. You've got some cards that someone thought was a good idea, but on further review, they're not actually so great. What would you do with the cards? Would you create an separate section on your wall for these worthless ideas or would you chuck them in the nearest waste-bin? Yeah, you'd toss 'em, so would I.

So what makes Jira any different? Delete them.

---

I'd like to muse on what makes Jira different from a physical wall for a moment. The difference between the two is that if you kept the physical cards, they'd be much more noticeably in your way. People have a tendency to want to keep ever half baked idea anyone has every had in an electronic system because it's very cheap and easy to do so. You don't notice how in your way those junk cards are most of the time, but they are. Every time you have to manually filter through garbage trying to find what you really need, you've shot yourself in the foot. Worse, you've shot your team and company in the foot. People are the most expensive part of most projects (and any software project). We shouldn't waste their time by digitally keeping around something we would throw in the trash if it were a physical card.

Answer 2

At our firm we have a few ways of tracking out-of-scope tickets, all of which have proved useful for different Product Owners depending on their style.

1. Issue Type: In addition to JIRA's normal "User Story" issue type, we've created a separate type ("Iterative User Story," but you can call it whatever you want) that indicates an issue is outside of the scope of our original project. Whereas Agile and Scrum allow for iteration and flexibility when it comes to scope, it's perfectly acceptable for a PO to prioritize one of these over an "in-scope" story in the Product Backlog with the understanding that it will (1) affect what makes it into a release and (2) be more valuable than an in-scope item which it displaces. Tracking these as separate issue type makes reporting in JIRA a breeze -- we can easily tell customers how many "out-of-scope" user story points have made it into a version
2. Icebox: In every backlog we have several versions -- the version we are currently working on, the next version or versions, and an Icebox. The Icebox is a repository for ideas that someone on the team has that should make it in eventually but are not yet prioritized into a release. It's important to clean out the icebox every time you release a version, otherwise it gets too cluttered, but this can be a useful tool to say "is this still something we want to do, or not?"
3. Deferral: We created a status in JIRA called "Deferred" for issues that we simply won't do, can't do, or otherwise won't happen. Anything that is out of scope can be deferred with a resolution of "Won't Do" and given a comment as to why ("this item was out-of-scope and will not be put into the product any time soon.") Deferral is preferable to deletion outright, as we can still search for the issue, see that we had the idea before, and determine whether the reason we did not do it is still valid.
4. Deletion: The final option, of course, is to just delete something if the issue is out of scope. As another poster pointed out, this is what you'd do if you had too much stuff on a classic wallboard. I think what is missed in this analogy is that JIRA does have some pretty powerful searching and filtering functionality which a classic wallboard doesn't have.

Answer 3

With one particular client, what we did is mark those cards as "Cancelled" status to keep track of the reason why we considered those out of scope.

Then, to keep the backlog clean, we filtered those cards out of the actual board for the project. This way, they won't get in the way of daily work, but remain accessible for reference if needed.