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:
- Specifications masquerading as user stories, thereby generating waste.
- 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.