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?

  • 1
    what tool do you use to support your kanban board? Commented Jan 24, 2018 at 18:05
  • You need a new category for these stories. They do not belong in the pending stories but they do not belong in the done stories either, Deleting is not an option since it may be needed as history reference. Commented Jan 25, 2018 at 7:03
  • We use Jira. And, yes, agree that we need a new category. Maybe. Looking to reopen local discussion with whatever I hear here. Commented Jan 26, 2018 at 14:24
  • For now, the working process is to drag obsolete stuff back to the backlog with a tag, "obsolete" and a comment explaining why. That keeps it out of "done" and it is easy to push down the backlog and keep it out of people's notice. Should we decide to simply delete these later, easy to automate and do. One benefit of this method is that it requires no customization--high on the list of current corporate directives ;-). Commented Jan 26, 2018 at 14:54

2 Answers 2



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.

  • Although by-the-book correct, I've run into the problem described in the question and this doesn't work. In a regulated environment, you may have independent QA. If work spans multiple sprints, it can be "done" in the sense of all shippable development done, dev testing done, and automated + manual test cases written and dry run. But you need to execute those independent test cases right before it goes into prod, which could be two or three sprints later. But you want to see and report on what is "done" in a given sprint and track a PBI to deployment.
    – Thomas Owens
    Commented Jan 24, 2018 at 19:45
  • In common with the previous commentor, I agree emphatically in principle. I =do= take occasions where this issue arises as opportunities to take a look at how we write user stories. But, the issue does arise, even though, in theory, it shouldn't/can't. So, I guess I'm asking how other people deal with these cases. (So far, I have deleted such stories. But I have some that it would be convenient to hang onto, hence the question.) Commented Jan 24, 2018 at 20:02

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.

  • 1
    Kudos for mentioning Reinertsen’s work. Personally, I think 80% success is more optimal, but I've heard 50% bruited about by a number of people. If you can include a citation for that, I will totally upvote this.
    – Todd A. Jacobs
    Commented Jan 25, 2018 at 12:32
  • @ToddA.Jacobs Of course there’s no formula for this. Reinertsens 50 is very much s theoretical ideal. For Pharma 10% could be the sweet spot. For developing in mature or commodity industries like new types of steel it’s probably around 90%. What should I find a quote for in order to earn a precious upvote?
    – Kurt
    Commented Jan 25, 2018 at 15:39
  • You said Don Reinertsen says the optimum failure rate is 50%. However, The Four Impostors: Success, Failure, Knowledge Creation, and Learning actually says 50% is an optimum failure rate for binary tests to reduce uncertainty. Maybe I’m misunderstanding it, but I’m not sure how applicable it is as a general goal for agile contexts (vice Story Spikes). A more targeted citation or broader explanation would help me a great deal to understand what you’re saying in the OP’s context.
    – Todd A. Jacobs
    Commented Jan 25, 2018 at 16:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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