How do you handle user stories that become obsolete/irrelevant?

Question

We have a few user stories that, in the process of our work, have become irrelevant. E.g., in order to enable customers to xx, we need to yy so as to. But, then it turned out that there was another approach to xx and yy was irrelevant. (Granted, this is likelier when we do overly specific user stories--another topic.)

If I delete the story, there is nothing obvious in place to communicate, "nothing to see here, we've moved on." But, neither is there a usual column, tag, or category for, "we thought we were going to address this question, but it turned out not to be useful/relevant/whatever."

I'm thinking of adding a tag, "not done - obsolete" and dragging the story into the "done" column (e.g., no further work to be done, but if you want to know what happened, read the comments).

What do other people do?

Answer 1

TL;DR

Work-not-done isn’t really done per the Definition of Done, and therefore has no business being placed into the “Done” column of a kanban board. It should either be discarded or returned to the stakeholders for refinement.

Digging deeper, you may have two related issues to examine:

1. Specifications masquerading as user stories, thereby generating waste.
2. A political or process issue leading to a desire to track work-not-done.

Both of these are anti-patterns that I address in more detail below.

User Stories Aren’t Specifications

The first issue is that your user stories are probably specifications in disguise. A well-written user story isn’t prescriptive. For example, you say:

[I]n order to enable customers to xx, we need to yy so as to...

While it appears like a traditional (if inverted) user story, this is really more of a specification because it’s prescriptive and deterministic. Consider your posted format with some values plugged in:

In order to enable customers to withdraw money, we need to have a PIN pad so the user can enter a PIN value.

A more flexible user story format is one where you describe what the customer wants to do, but leave the implementation up to the team to determine during the iteration. For example:

As a bank customer,
I want to be able to withdraw my money at any ATM
in a way that’s easy for me, but ensures other people can’t withdraw my money.

The first example is a specification that predefines what’s to be built. The second example lists a goal and provides some context for the user experience, but leaves the implementation details up to the development team. Could the solution be a PIN pad? Sure! But it could also be a retinal scan, a fingerprint reader, or something else that no one outside the team has thought of yet.

By focusing on the value to be delivered rather than specifying an implementation, your team is much less likely to experience the type of work-item invalidation you’re describing. Agility is about embracing change, but work should not be routinely invalidated within an iteration through overspecification.

When Bad PBIs Happen to Good People

Even when a user story is well written, business goals change, new information is discovered, or planned work becomes unnecessary. Each framework has its own way of differentiating minor changes from critical-path changes, but in general all agile frameworks treat this as a opportunity to maximize “work not done.”

One of the most under-quoted principles of the Agile Manifesto is:

Simplicity--the art of maximizing the amount of work not done--is essential.

While iterative development generally entails some amount of continuous rework, being able to avoid known misfeatures or unnecessary effort that would otherwise sap a team’s capacity to work on value-generating activities is a critical practice. In this case, the fact that you haven’t already done some unit of work that turned out to be unnecessary is a win!

In Kanban or Scrum, if you find muda (waste) then you should collaboratively discard it. In Scrum, this means checking in with the Product Owner to ensure that discarding the story doesn’t impact the Sprint Goal. In Kanban, you may have to evaluate whether the kanban card really represents an expected unit of output that someone is waiting on, or whether it’s irrelevant to the product or value stream, and then act accordingly. However, since the goal of most frameworks is to deliver work, not to track the quantity of work-not-done, explicitly tracking irrelevant or obsolete tasks is a framework implementation smell.

Answer 2

This is completely normal. In a true end to end agile process, the way it has always been envisioned, there hasn’t been waterfall style requirements analysis and complete breakdown of specifications into user stories. Or as the trendy people call it these days, the process should include both discovery and delivery. In pharmaceuticals we might start to develop 10 products before we decide that 9 of them are not worth developing to completion so we throw them away and work on the winner. Don Reinertsen says the optimum failure rate is 50%. If we are completing 100% of the user stories that enter our process, then we are either doing pure “delivery”, or we are not innovating. I prefer to just delete them, but it could be interesting to have different “bins” at the bottom of each process stage so you can collect statistics on how many and where do items of each type actually leave the system. You can use this to decide if you are innovating enough, i.e. if you aren’t throwing enough away half way through the process.

Edit: I really have to emphasize, if you end up throwing away stories rather than delivering them this DOES NOT mean something is going wrong with the “user story writing” or that something needs to be fixed. On the contrary. If you AREN’T throwing away enough user stories THEN I would have a close look at what’s going on. You don’t need an agile team to slog through a backlog and type in a bunch of user stories that have already been practically developed by “the business team” or “in the discovery phase”. In such cases its typically these business guys or the discovery process that is in need of agile. The source code typists can simply pull tickets.