Stop creating tech stories

Does your backlog contain technical stories like migrations, upgrades, refactors, and other chores? Are you writing tasks instead of real user stories? Let’s see why this is an antipattern.

I’m a fan of continuous codebase improvement through constant refactoring. I love coding and I care a lot about all the codebases I work with. I understand migrations and upgrades need to happen, so why do I propose we stop creating technical stories? There’s a lot of harm in doing so. Let’s see why.

A tech-driven approach

What are you paid for? I often hear “to write code”. I don’t agree with that at all since I believe we’re paid to deliver useful functionality. Delivering value with a single line of code is a million times better than opening a 750-lines-pull-request devoid of value. “But I wrote so much code today!”. This is not about you or the dopamine rush you feel when looking at your flashy GitHub mosaic; this is about the users and the business.

As professionals, we need to understand that a software project is not about us and our egos […]. The Software Craftsman

I know you want to feel you’re getting stuff done, but that might produce insignificant value to the users. Being very busy doesn’t correlate with doing a magnificent job. Developing software is much more than coding. You’re supposed to get involved, ask why, validate, and chase the people involved. You are part of something bigger. If you want to code, have some fun at HackerRank or Advent of Code. Real-world projects need more than that. There’s a reason they’re called user stories.

As a side note, I hate when someone says the team needs to be protected from the customer (or the stakeholder). Well, protected from what? From doing their jobs? Are you an executor or a software engineer?

Kids love toys, developers love tech. This can degenerate into a team of technologists who works for the technology itself. But technology is not the goal, just the means for it.

Developers may deliver many tech stories and believe they’re doing good, but who are they helping? Those stories only add clutter and visual load every time someone visually scans the backlog. They only make sense in the developer’s mind. They may lose their significance because of business changes, making them wasteful. Even worse, they may give the team a false sense of delivering a lot. Outputs are not outcomes.

The value of software is a vague and esoteric concept in the domain of business users, but task size is under the control of a delivery team, so many teams end up choosing size over value. This results in technical stories, that is, stories that don’t really produce any outcome, and a disconnect between what the team is pushing out and what the business sponsors really care about. Fifty Quick Ideas To Improve Your User Stories

Some projects ago, I used to add technical tasks to the backlog, thinking I was doing a superb job of keeping the codebase tidy, but I was wrong. Engineers will over-engineer, creating a bunch of abstractions and doing unnecessary refactors if they don’t know the reasons behind things. How many unnecessarily complex systems resulted from engineers' over-engineering? I’ve witnessed a few. So what’s wrong with protecting us from ourselves?

Implementation details

I remember some cases in my career where the team lost track of why they were doing something. Sometimes, it was only because it was on the backlog for some months. That way, the stories become disconnected from their original intent. Who knows if it still holds? If the story is technical, it’s hard to tell as tech stories lack connection with the business goals. Ideally, any story should connected with the business, and anyone — developer or not, new hire or not — should be able to grasp the end goal of any story on the board. The answer should not be purely technical. User stories should be relatable and phrased with business domain terms, not technical jargon.

In fact, Apple didn’t introduce the iPod until twenty two months after Creative’s entry into the market. […] The problem was, they advertised their product as a “5GB mp3 player.” It is exactly the same message as Apple’s “1,000 songs in your pocket.” The difference is Creative told us WHAT their product was and Apple told us WHY we needed it. Start With Why

Tech stories are developers’ to-do lists since they materialize what they have in mind to accomplish something meaningful. “But it doesn’t scale. I need to refactor!”. If you’re sure, then you have a user story but frame it as such (you may even find out you don’t need to do it at all).

How can you prioritize work when all you see is a technical to-do list? Per each task, you need to ask why so you can make any sense of it and decide about urgency and even the need to tackle it. Instead, why not list the actual reasons — which equates to user value?

Tasks are implementation details. They solutionize and that’s a bad thing because it’s too soon. For example, if you say “Implement HTML validation”, you’re committing to a solution. Consider “Help users avoid and correct registration errors” so that the team can think creatively about the range of solutions (e.g. the team may decide that server-side validation is sufficient). Even worse, tasks are potentially horizontal slices of work: they don’t deliver value on their own (it promotes leaving things unfinished). Instead, you should encourage vertical slicing, as we’ll see later.

A user-centric approach

I can summarize my proposal to deal with tech stories in three parts:

• Don’t create the tech story at all. If it’s a simple agreed thing or it’s blocking the team, does everyone need to see it on the board? Why does it need the bureaucracy of a typical story? Why create a story at all? Just do it, eliminating the story’s overhead.
• Rephrase the tech story in user terms. Rather than “Add an index to the accounts table” consider “Improve search account by name performance”. Besides making the intent and value clear, we leave the solutions open to discussion. If there’s no way to frame it as user value, is it really worth doing?
• Create tech stories as tasks under a real user story. This way, they are always justified by users’ needs and can be tracked together. Tech stories may be part of something bigger — the real user story — but then someone has to keep the big picture in mind, which might get lost along the way. Avoid single points of failure.

“But I need to refactor this garbage!” Why? Are you sure it’s not just for the sake of it? Maybe yes, maybe not. Ask why until you see the benefit. If the answer doesn’t involve the user, don’t do it.

All we do must have something to do with the users or the business, so ask why until you get there. Real user stories can act as beacons that point out the reasons. The Connextra template may help as a starting point (but it’s not to be seen as a dogma). What if your product is a low-level driver or an IDE? OK, in that case, your users are other developers but treat them as such by creating stories for them.

“But I need to update this library to make my life easier”. OK, do it. But do it when triggered by some user story that would benefit from it. Is tech debt in the way of delivering a feature? Then do it. The user story may become bigger, but that reflects its actual cost (you can still split it into tasks).

Having refactoring tasks can also mean you’re not doing them frequently enough, so refactor regularly rather than as a special effort. Sure, mitigate tech debt and keep code healthy, but do it when you bump into it — after or before the story (never simultaneously). This can lead you on a path of doing only what’s needed — perhaps you didn’t need a full-blown database migration; perhaps you could refactor only what’s required for the user story, which is certainly better than a big-bang-refactor; perhaps you didn’t need to bootstrap a full-blown project, but just the minimum to show value in the following demo.

I’m not telling you to stop doing technical improvements. All I’m saying is to put them in context. Give them a reason to exist by doing them while working on a real user story.

If you need to create a tech story, pause for a while. Here are some suggestions on how to deal with it:

‣ Is it small and agreed upon by the team? Is it blocking development or delivery? Just do it without a story’s overhead. Warn the team if necessary. ‣ Can it be reframed into value for the user? Ask why multiple times. If you find value for the user, rephrase the story. Otherwise, consider deleting it. ‣ Is it a spike or investigation? Do it under the story that gave rise to it. Document the results in the story. ‣ Is it going to make development easier? Is it necessary to deliver another story? Do it in the context of the next related story. Create subtasks for it. ‣ Is it too big? Can it be vertically sliced? Can it be described as a change in user behavior?

You might say you’re disciplined and still want some tech stories, but can you guarantee they don’t set a precedent? What message does it pass?

“Wait… but my users are the frontend developers using my API!” or “As a developer, I…”. This is cheating. User stories should encompass all it takes to deliver value to users, not developers. This concept needs its article, but to sum it up, it implies that backend devs, frontend devs, and UX, among others, should work on the same stories rather than slicing teams by software layer (e.g. frontend and backend). What’s the point of using only 10% of an outstanding API? Real user stories prevent that. Vertical slicing supersedes horizontal slicing.

Positive effects

Unintended consequences are outcomes of a purposeful action that are not intended or foreseen, i.e. for every decision, you have its intent and its side effects. A side effect often is a change in people’s behavior and mindset. The goal of avoiding tech stories is to focus the team on work that brings user value. As a side effect, it can influence the team’s perceptions of their jobs. The team might learn more about the business. They can be leaner and wiser using technology and see it as a tool to improve people’s lives. Who knows if the overall system complexity is reduced by some subconscious effect on people’s minds, as in a self-fulfilling prophecy? I may think wishfully, but the team may learn to see things through the users’ lens.

Not creating tech stories at all may sound extreme, but caring about the users of our products should be a priority. It’s seeing technology as a means to an end. It’s about not being selfish. It’s about reducing the risk of waste.

Remember that even though we build software, the goal is not technology; it’s business value. You can take my advice as an invitation to rethink and reorganize your backlog. At worst, the amount of work remains the same. At best, you’re preventing wasteful work while promoting good values in your team.