2

Our team noticed during this Sprint that a user story is not plausible to do from a technical point of view. We approved this decision with our stakeholders and client and we want to mark this user story as "will not be implemented" or something similar.

I can't find any official documentation on how to deal with these sort of user stories. Is there an official way to mark these user stories and are there some functionalities in the tool Jira for that?

1

TL;DR

From a formal Scrum perspective, the format and contents of a Product Backlog Item such as a user story is undefined. The Product Owner is solely accountable for its contents, and must ensure that "the Product Backlog is visible, transparent, and clear to all." Scrum doesn't formally specify any other artifacts, so creating a special status outside of the Product Backlog is going to be either idiosyncratic to your project or a known anti-pattern.

Rather than track this sort of dead weight, it's often better to communicate with stakeholders about the story. Either alternatives can be found, or the story is treated as an ephemeral artifact that will be removed from the project's collective consciousness, to be revisited in the future if needed.

Agility is about collaboration and communication, not spelunking through long-buried artifacts. If you're creating an artifact just to archive it, don't. There are more agile approaches built around people and interactions.

Perennial Low-Priority Stories: An Anti-Pattern

Within the Scrum framework, a Product Owner could keep "won't do" items forever at the bottom of the Product Backlog, but this is usually a bad idea that's covering for some other process problem.

First of all, consider the point of tracking won't-do items in the first place. Teams or stakeholders generally implement something like this either as an accountability artifact (e.g. "Bob brought this up; we looked at it rather than ignoring Bob; it's not feasible.") that nobody ever dredges up unless people are pointing fingers, or as a (largely ineffective) mechanism to prevent duplicates entering the workflow.

In a large or long-running project, the Product Backlog continuously grows and evolves. Over time, more and more won't-do items will get added to the tail of your Product Backlog, to be either totally ignored or as a growing form of technical debt that must be paid by constantly revisting old items.

Keeping won't-do stories on the Product Backlog also fails as a duplicate-prevention control, because free-form text comparisons are hard to automate, and user stories can vary just enough that two almost-identical stories are rarely exact duplicates. This also creates technical debt, because now the Product Owner has to compare each incoming story to some legacy story to see if it was already addressed. Even if this wasn't cumbersome, it's also pointless because the business context around why a duplicate or similar story is being introduced now is more important than the fact that something was addressed at some point in the past.

Additionally, the reasons something was impractical in the past may no longer be so. Keeping legacy decisions around serves very little purpose other than CYA. The real question for the Product Owner is whether the requirements have changed, and whether the team can provide a solution for the current need.

Other related solutions simply create zombie stories or additional reports and artifacts that create very little value, but often involve additional process overhead. The basic advice here is "just don't."

Solve for X with Communication and Collaboration

Another reason people want to keep zombie or discarded stories around is because they have an X/Y problem. For whatever reason, communication or collaboration with stakeholders or customers is poor, and rather than fix the underlying process issue teams try to mask them through artifacts like rejected requirements. Don't do that either.

The Agile Manifesto's four core values are:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Zombie stories or rejected requirements don't really reflect any of the values on the left. There are more agile approaches to the need than keeping legacy artifacts around forever, creating drag.

Find the X in an X/Y Problem

First of all, consider the need. If Bob in accounting keeps requesting Feature X, there's probably some business need or workflow issue that Bob thinks will be solved by implementing this feature. As long as this underlying need remains unfulfilled, this backlog item or ones just like it will keep cropping up as they should!

Rather than "rejecting" the story as infeasible, the Scrum Team should collaborate with Bob to figure out the underlying problem that the feature is supposed to address. Maybe there's an alternative solution that the team can implement, or perhaps there's something that needs to change about the organizational process or workflow. In any case, rejecting a request or trying to block future requests of a certain type is the opposite of collaboration or embracing change.

Involve Stakeholders; Don't Status Them

Secondly, marking Product Backlog Items and keeping them around is a proxy (and a poor one at that) for effective communications. Rather than talking to Bob, or collaborating on a solution, the Scrum Team is attempting to rebuff or block Bob in a non-personal way by labeling or categorizing the backlog item. This is a way of limiting communication rather than opening up a dialogue, and is therefore non-agile.

Bob deserves some direct feedback. This may be from the Product Owner or from the Development Team, depending on the disposition of the item, but in any case someone should talk to Bob. Bob is an individual, and should be treated as such. If he's a stakeholder, then he's part of the reason the Scrum Team has formed, and should therefore have visibility into the team's capabilities, priorities, and resources. If nothing else, knowing that what he's asking for is infeasible and why could help Bob make better use of the product or find an alternative solution on his own.

Embrace Change

Finally, zombie stories are an artifact that assumes the project or its business context will never change. Teams gain and lose capabilities, products evolve, and the business environment is rarely static. A story that was infeasible six months ago might be practical now. A story that was too resource-intensive before might have a new technical solution. Something that could be dismissed as impractical in the past might be sufficiently business-critical today that finding a solution or throwing more resources at the problem are essential to the business.

By keeping the Scrum process free of legacy decisions, you free up the team to address backlog items within the current context. Why does it matter if someone brought up this story last year? It's important now! Why does it matter if it couldn't be done before? It might be possible now! In all such cases, the important thing is to address the current need in the current context, and to prioritize it against current project resources. Anything else is not embracing change.

1

I can't find any official documentation on how to deal with these sort of user stories.

If by 'official' you mean as described in the Scrum Guide, then there is none. Scrum generally doesn't go into details on the how-tos, leaving it up to the Team to determine those for itself.

are there some functionalities in the tool Jira for that?

Sure. What my team does is just add (Rejected) to the start of the summary for the Issue and put it to Done. Since that's simple and good enough for what we need.

A more complex approach would be to add a workflow transition to Done that sets the resolution value to a certain value (e.g. "Won't Do").

There are various ways; you should find one that fits your Team.

0

There is no "right" answer to this. If you want to keep it for tracking purposes, you should be able to archive it as discussed in this Atlassian community post.

However, if you don't specifically need to track it, you can just delete it (from a Scrum standpoint).

0

When you resolve a story in JIRA you get to select the resolution from a list.

JIRA comes with a bunch of standard resolutions like: Done, Won't Do, Duplicate, etc.

However you can also add custom resolutions, so you could add a resolution called "Will not be implemented".

You can add a custom resolution by going to JIRA settings -> Issues. Under the ISSUE ATTRIBUTES, select Resolutions. Click add.

More details on adding a new resolution here.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.