Sep 18

Technical userstories: pick a side

Battle of Hastings

In almost every project that I know of the question emerges what to do with technical user stories. At first I was inclined to just say that there is no such thing as a technical user story and that all stories on the product backlog and scrum board should be functional. Even though something can be technical, it always serves some sort of function and therefore it has a reason why you want it. And if you have a reason and a function, the next step is the business value and from that the priority. But this is easier said then done. In the real world there are all sorts of reasons that teams want technical stuff done that doesn’t mean anything to the product owner. So how to handle this question.

I have dug a little deeper and the answer isn’t that simple. There are a lot of pro and cons in the agile community. On one side people say that you should simply allow anything on the board as long as it is visible and helps the team to deliver. And on the other hand, a team should not have technical stories in the first place if only they would deliver bug free software without any technical debt.

Ron Jeffries  provides three Reasons to NOT Have Technical User Stories

  1. PO stories should inherently be built with a creation of tests and a creation of clean code from the beginning.
  2. Since systems are built incrementally, the design should be built incrementally as well. In order for each feature to be really “done” design must be done with development.
  3. The PO has no real ability to prioritize technical stories, and shouldn’t have to. They prioritize the standard stories.

More about his reasons on his blog

This sounds very well and I agree for some part. But I think this is a bit short. So how can we win this war. I think we can’t. They only way to solve this is to just simply pick your battle and see how it goes from there. And in order to win it, here are a few ideas and quotes from the agile community.

I’m generally against technical user stories. “Working software is the primary measure of progress.” The product owner should be able to judge that progress based upon principle #1, “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Value must be determined by the customer, not the Dev Team. Rarely have I witnessed a technical story provide value in the eyes of the customer. Thus, user stories should be in the form of value in the eyes of the customer which eliminates most usage of technical stories. – Brian Levy


I strongly believe that the Scrum board serves best when it makes the entire team commitment for a Sprint transparent. Anything consuming team capacity belongs there. This is essential for self-managed, self-organized teamwork. Enabling work, like what a Sprint zero is about, is a perfect example. And that continues into normal sprints as needs are discovered. Also commitments to actions from retrospectives are appropriate as well as spikes. As far as the PO knowing how to prioritize this, consider these points:
- the PB priority is input to the team making commitments in a Sprint/iteration planning meeting.
- the team chooses and makes that commitment – with buy-in from the PO, but not in obedience to the PO. They are self-managing for all the benefits that brings.”– Jay Conne


In case you have very many technical user stories, which could sometimes be the case if you are creating a new base platform or generic error or mail handling for use in a common library etc it might be an idea to switch product owner to have a product owner who understands the technical stories and can prioritize them correctly. We have tried this approach in some cases when starting up a completely new project. In the first sprint we had an “internal” product owner and when the architecture was in place we switched to the business product owner.  – Fredrik Carleson


If you have known technical debt then it has a cost and therefore a value associated with repaying that debt. I can see no reason why teams should not be open and transparent about that known technical debt by creating product backlog items for the known technical debt (although I would not personally consider these as user stories as they do not provide customer/user value). Scrum does not say teams have to use users stories or that user stories are the only type of product backlog item, or indeed that the product backlog should only contain one type of product backlog item. 
If teams “hide” the technical debt and repay it without the Product Owner being aware, I would consider that to be a very bad smell as them team are not living the values of agile or scrum. 

Also, if teams are open about the amount of known technical debt in their product, they can also use this data to gather insights as to how and why the known technical debt has been accrued and then use these insights to adapt what they are doing to improve, i.e. reduce the accrual of known technical debt. This will enable the team to improve. Maybe the team could have a retrospective focused on technical debt? – Iain McKenna

These are just a few ideas that I think hold value. But every project, team and company is different. Every situation demands a unique approach. You can claim that it should al be by the book. Because that book isn’t written by one person, but is written by all of us, what version should you read? As this is stil an open issue I would like to hear from you. What is your idea to win the battle on the technical user story and come out victorious for both team and business.

Permanente koppeling naar dit artikel: http://agilethings.nl/technical-userstories-pick-a-side/

  • Arne Timmerman

    As always, everything depends on the context. If you start a project on a brand new code base, then you should try not to introduce technical debt at all, of course. But as you all know, this is not always the case..

    I don’t like the idea of technical user stories, because they are hard to explain to a product owner. Most of the time they should not be prioritized by the product owner either, because he simply can’t make a correct decision. A team should make considerations at this point.

    I like to apply the Boy Scout rule when talking about this subject: ‘always leave the campground cleaner than you found it’. When a team estimates a user story they should also discuss the technical debt that is probably related to the code that will be changed. If they think that the effort to remove the debt for this code is higher than normal, they should visually mark that story in a way that the product owner knowns that the story possibly requires more effort. If desirable, they can increase their estimation.

  • Niels Talens

    I think your sentence “But every project, team and company is different.” answers the question of the title quite well. It all depends so much on the situation and the people that you cannot simple choose a side by forehand. 

    Choosing what seems to be the right solution for a situation at a moment is one part. Adjusting it if it doesn’t seem to fit or things change is the more important part. 

  • I don’t agree it depends on context/environment. It sounds more like an excuse not having to look at the root cause of the ‘stories’ addressed.

    I’m not in favor of (naming) technical stories. I prefer to couple stories to users where the users can be all stakeholders; including the developers/architects, people maintaining a system. In relation to quality attributes like for example maintainability the user stories will be of value to these users (and other stakeholders). 

  • rashmi

    I am new to agile. Product owner has sound technical understanding. And project is to adapt existing production deployed app for other countries i.e. minor enhancement project. So PO given us likely changes in application and asked us to create tech user stories. We are not sure what to providd in tech sgories. Could you explskn me how much technical depth a tech story must have?? How big should it be? What type of detail it should have? Can you give me example for UI change and batch job change? Say change validation rules as per place selected. Job– process different country files and store data in table. Both are just modifications.

    thanks in advsnce.


    • Wel. To my opinion there is no such thing as a technical Userstory. As soon as you ask why something technical needs to be done, you might get you answer that writes the story. For example: “We want to change the database” If you ask why, the reply might be to makes a search go faster. So the story should than be “as as user I want to have my search results to emerge much faster so I don’t have to wait to long.” This in response might turn out to be that not the database has to change but something els. Technical user stories are not provided from the user point of view, but emerge from a developer point of view. And therefore are in most cases less important because the business value is not determent by the PO. The PO in your case needs to be much more specific about why he wants things not how. it is not his concern to ask for technical solutions. Always stay on the functional side. Don’t drown in technical specifications. I cannot provide you with examples as I’m not a developer, I can also only thing in function. As I said, alway answer the Why question. If you cannot find the answer then don’t do it.

  • Tim Field

    The problem for me is that most technical stories roll up to some sort of business value and are therefore necessary. If they don’t then, they should be outed as a waste of time. Take a really heavyweight technical project like identity and access management, the business value is logging in so that you can use a system (ignoring RBAC). To make that work you may need a really large number of technical tasks behind the scenes. You could argue that the Epic is “As a person I want to log in to System A so that I can do my day job”, no product owner is going to have an issue with that. Then you reach the obvious conclusion that that won’t fit in a sprit and could be 8 weeks work! Building servers behind the scenes and security between various components. I prefer to switch to making the “so that” part of the smaller story understandable to the product owner…. I want to secure the pipeline between A and B so that nobody can hack our system. You should be able to explain the point of what you’re doing to a PO. Prioritisation for me then moves to the feature level with an explanation of overall size of the change fed back to the PO. So if you’re priority is to log in rather than enter a new password we can talk about that. The PO maintains overall control of the backlog but doesn’t get lost in the weeds of technical “value” hidden in lots of smaller stories.