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:
- Who benefits from the result?
- 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)