The user story in development was deprioritized, what now?

Let’s say you have a Kanban board like the following:


Then, suddenly, the P.O. discovers that the features D and E were developed by a competitor and that you are losing users because of that. Therefore, the P.O. decides to deprioritize story C. This is only an example of why a card might be deprioritized in the middle of its development. But now that it was deprioritized, what happens to story C?

Well, to answer that, let me make a parallel with an alcohol-based perfume company.

In the backlog column, the company has the bottle ready to be filled but no fluid yet. When the bottle starts to be filled, the card goes to “in progress”. When the bottle is totally filled, the bottle is closed and the card goes to done.

Perfume flow

So what happens if another perfume suddenly receives a priority greater than the priority of the bottle being filled? Well, as we all know, alcohol-based fluids are volatile and, with time, they will completely evaporate, requiring them to be refilled.

Perfume flow volatile

The same happens with the story and its code. With time, the code that is inside the story gets obsolete and unnecessary, losing its value. What to do with the story depends on the following rationales:

  • How long will the story C stay in the same stage?
    • If the story stays too long in the same stage, some part of the work may get useless, therefore, you could just remove it from the board and put it back on backlog, since some refining might be needed when this story is chosen gain.
    • If the story will stay there for a short time, you may want to leave it there and, when it can be worked on, you may still use what was already developed.
  • What is the value story C will generate after being done?
    Let’s say that the return on the development of that feature is small. Is it worth to pause its development and run the risk of investing even more money on the development later? Will the return on its development be greater than the development time?

For this to be true, the following needs to happen (visualized in the chart below):

  • $ spent with initial development + $ spent with rest of the development < story C $ return
    • The amount spent with rest of the development will increase with time, since the initial development starts to lose value.
  • If the amount spent is greater than the return, it is better to ignore the functionality. However, this math is not as easy as it seems… You need to account for risks, increased revenue, increase the number of users of your product, etc. So be careful!


Therefore, based on those, you can possibly do four things:

  • Leave it on the column and restart it when its priority arrives
    The pause will be fast and will not harm the development of the card. In this case, it is important to flag the story somehow so that the whole team can see that the story is “blocked” by the P.O. due to its prioritization.
  • Take it back to the backlog, and restart it when its priority arrives
    The pause will be long and the card will need more refinement.

  • Finish it first, before getting another card
    The card is almost done, and if you stop it, it will not generate value anymore.

  • Cancel the card
    The card is a long way from being finished, and its value is too small to pay for the time it will be paused.

It is also important to notice that this should NOT be a common thing in your process. If it is happening too often, you may need to work on your prioritizations!

What are your thoughts on the topic? Leave your comments below 🙂

Download: Forecasting software project through Monte Carlo simulation (FREE spreadsheet)

Comments are closed.