One of the first thing they tell us about stories, is that they should be valuable. That’s what the ‘V’ in INVEST stands for:
Taken from: http://en.wikipedia.org/wiki/INVEST_(mnemonic):
V – Valuable – A user story must deliver value to the end user.
That suggestion usually sits quite well with business side people, which nods in agreement when they hear this, but generally raises a few skeptical eyebrows over at the technical side of the room. Which soon turn it into the following question:
So how should we deal with all the technical things that we need to do and have no direct value to the end user? Things like replacing our DB technology, working on infrastructure, or building some inner development tools?
A very good question indeed.
What is Value?
The first thing we need to understand before we tackle this question, is that value can take two main forms:
- Value can be linked to things which increases revenue, and
- Value can also be linked to things which decreases costs.
Once we agree to that, we can see that “regular” stories usually falls into the first category of value. As we add new functionality to our product, it is capable of “solving” more business problem for our end users, which in turn are willing to pay more for our product. Or maybe that new functionality opens up more markets we can sell to. In any case, by adding more functionality we hope to increase our revenues. Technical stories on other hands usually fall into the second category. Most of them can be linked to some sort of “saving” either in our development process or directly to the costs of operating/using the system. For example, investing in our logging infrastructure, usually helps us developers in locating and fixing bugs, reducing the costs involved in fixing them (and yes I know it’s always better to avoid those). Investing time in setting up a one click deploy mechanism reduces the cost of rolling out versions to our customers which again saves money.
When dealing with technical stories, the trick is to try and quantify this cost reduction. Once we do that, prioritization is made easier, and the question of what is the value of those stories goes away.
Technical Debt
However, there’s another common type of technical activities that teams are turning into user stories. Those activity’s main goal is to reduce the technical debt in our product. Just a quick reminder technical debt has been term referring to all the things which we (as a team) know that we should have done in the past but for some reason decided not to do. For example, things like cleaning up the code, writing automated tests, improvement in system design, are typical things teams tends to leave for the future and starts to address them once they understand they can’t be postponed anymore.
Ron Jeffries made a strong case for not putting those on the product backlog (Refactoring – Not on the Backlog) and I totally agree with him. Normally, technical debt should not be turned into user stories and managed on the backlog, reducing debt should be an ongoing effort. However, many of the teams I see are just not there. They first need to learn how to do this continuously refactoring while working on other stories, and for that to happen they need to allocate time for learning. Putting stories in the backlog is one way to help them secure that time. But be warned, adopting this temporary solution as a long term strategy is risky. It is usually not enough and it opens up the door to accumulate even more debt with the thought that later on it will be turned into stories.
In any case, dealing with these kind of stories is a little more difficult, their direct “value” is usually less visible. Even if we treat it as a cost reduction it’s very hard to convince the business side that the value in rewriting parts of the system that currently works is big enough for the effort involved, and in many cases on its own it’s not. But here I would like to suggest a third kind of “value” and that is the value of learning. The real value of stories related to Technical Debt is that by allocating time for learning, not only we can reduce the amount of debt in the system, the team also learns how to avoid those kind of mistakes in the future. And that can be priceless.
If you also struggle with using stories to manage your team work, or find it hard to prioritize between all the things that your team needs to do. I want to invite you to attend our Agile Product Owner Workshop in this advanced workshop we deals with various issues related to managing your backlog.
Image by Anja on pixabay
