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
- PO stories should inherently be built with a creation of tests and a creation of clean code from the beginning.
- 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.
- 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.