Technical User Stories - Who, What and Why

One of the problems we regularly face with our more technical stories (for example, setting up a monitoring stack) is explaining to the people in charge of the budget why they should pay for this. It's a valid question. I think it arises because when we're writing technical stories, we forget some of the core elements of a user story:

• Who wants this?
• What do they want?
• Why do they want it?

The problem with a technical story is you can't say, "I want it because I'm a developer and I think it's the right thing to do". That's not really helping your product owner prioritise your technical needs against more obvious business requirements.

So you need to go back and think about the situation where you don't put in your monitoring platform, or you don't deal with that thorny bit of technical debt, or whatever. Who ultimately cares if your average response time climbs to 2-3 seconds and you've got no dashboard to tell you? Who's on the line when the bug-ridden legacy code duplicates or drops customer orders? That is the person who cares if things go awry in production - probably far more than your development team. They're the ones who should be agreeing, "yes, I want to spend time and effort on this" with product owner.

Once you've identified that person, it's easier to figure out what they want in business terms. You can ditch your, "I want the ELK stack so that I can have the ELK stack" story and write, "I want to be able to analyse and drill into average request times" which is what the person actually wants to do.

Then the final piece of the puzzle; why they want this. This should follow relatively easily. "So that I know when my customers are receiving a poor experience and can take steps to rectify it." At this point you're starting to think about the task in terms of what the problem is, not just the tools you might use to solve it. This helps you think about other facets of the problem - for example a Kibana dashboard is well and good, but if our goal is knowing when customers receive a poor experience maybe we want some alerts, too?

This is particularly important when it comes to technical debt. I enjoy refactoring but if you're trying to size it and balance it against project work you really need a goal, and some way to measure whether what you've done is a success. A real example: instead of "fix the XSLT mess" I got the team to "make results tables display consistently", which was the real problem we were fixing. The value here is that you have to look at all of your pieces of tech debt and think about how they're actually surfaced. Clunky session management, dropped carts, slow responses and errors falling into a black hole are bigger and more burning issues than code which looks a bit ugly.

The benefit of all this is that nobody is going to look at your board and ask, "why are the team spending all this time on technical housekeeping when we need features and business value?" Because everything is stated in terms of its business value - including fixing technical debt and adding reporting and monitoring infrastructure. Also, because you have a better understanding of the problems you're trying to solve, you can come up with better solutions.