How to translate “business value” of things that are technically important

by on April 19, 2011 · 3 comments

Agile teams often struggle with purely technical tasks. They just don’t know how to translate technical necessity into business value. This makes it difficult to prioritize technical tasks against User Stories. In this article, I want to show you how to transform the hidden value of technical tasks into visible business value to ease prioritization with all the customer driven User Stories.

User Stories should describe what a user wants the system to do. Purely technical tasks should usually be implemented as part of a User Story. But, sometimes there are technical tasks which cannot be directly linked to customer value. Things like “Upgrade to MySQL 6.0″ or “replace magic numbers with enums” need to be done. How can you prioritize these critical chores against User Stories? How can you make the product owner aware of the importance of such tasks (and the business risks of procrastination)?

To be able to put technical tasks into the product backlog for prioritization, just create a User Story for each of them. But, isn’t that cheating? Not if you can answer these two questions:

  1. Who benefits from the result?
  2. Why is this task necessary?

The answers let you fill in the User Story template (“As … I want to … so that…”). You just take the answer of the first question to fill the “As…” and second answer fills the “so that…” part. If you have difficulties answering the second question, ask the 5-whys for the task to find the root cause which makes that task necessary.

Here are some examples:

As a new developer
I want to see meaningful enums instead of magic numbers
so that I can maintain the code without breaking anything

As a DBA
I want to upgrade our database to the latest version
so that I can continue getting support on the forums without being asked to upgrade first

If you’re able to formulate your technical tasks as a kind of User Story, your stake holders will be able to understand the necessity of them and will be able to prioritize them along with other User Stories.

(Note: This article is based on Technische User Stories by Thomas Lieder written in German)

Did you enjoy this article? Get new articles for free by email:

Comments

  1. says

    Hi Matthias,

    thanks for sharing this – very nice article about a really annoying and significant problem. I noticed when product owner/management do not truly trust the tech team because they might think something like “business value” cannot be achieved by tech stories. These discussions are a challenging task :-)

    Cheers,
    Thomas

  2. says

    Re “sometimes there are technical tasks which cannot be directly linked to customer value”, some would claim no changes should be made that can’t be linked to customer value. Perhaps the linkage is indirect, but it should still be there. Being able to “maintain the code without breaking things” has business value. The value isn’t really breaking the code or not per se, it’s more that you can continue to meet customer expectations for innovation without sacrificing quality. I believe it should be possible, and we need to try, to translate technical necessities into language that has meaning for management, marketing, and customers.

  3. says

    Jeff, you’re absolutely right. Above I try to show a way to do exactly that: translate technical necessities into language that has meaning for non-technical audiences :-)