Scrum By Example is a series of stories about ScrumMaster Steve who is the ScrumMaster for the WorldsSmallestOnlineBookstore.
While working on the FedEx 2-day shipment story Martin discovers some very crufty code in the Foobar class. He doesn’t need to work in the class to complete the story, nor can he see it causing any bugs right now. He doesn’t want to ignore the issue so he grabs an index card and writes “Foobar class is very crufty and it will slow us down later”.
Later in the day the following conversation occurs:
Martin: “We need to rework the underpinnings of the Foobar class so that we can work faster.”
Product Owner Paula: “Martin, why is that important? Help me see that.”
Martin: “It’s slowing us down. Every time we work in Foobar we spend an extra 20 minutes just trying to understand the mess that is there. If you write a User Story and give us 5 days it will all be perfect.”
Paula: “Can I trust you? Will this be the last time I ever hear about the Foobar class? Where should I put this is in the Backlog?”
Analysis
As we can see, there are several problems at play here:
- We’re expecting Paula (the Product Owner) who is the business domain expert to make technical decisions.
- Martin is making promises they can’t guarantee: “Give me 5 days and Foobar will be perfect.”
- User Stories must deliver real value to actual users.
- Making this problem a User Story pretends this work has real value, but we’re doing it because we weren’t really done with the original work in the first place.
The Product Owner should be focusing on work that affects the actual Users or other Stakeholders, not technical issues inside the system we’re building.
Instead of bamboozling the Product Owner I find it more effective just to pay an ongoing tax in the range of 15-40% (depending on the state of the code base) and then maintain a separate list of technical impediments/items.
Such a list would include notes like the Foobar class that needs simplifying; tasks such as configuring a CI server or upgrading a test machine, or anything else that the team is doing to help themselves. I wouldn’t bother including small refactorings (less than an hour or two of work); I just do those and get them finished.
In addition, issues like the Foobar class are best addressed when the team is already working in that part of the code or the issues are causing problems elsewhere.
If for some reason you really, really, think you must have it on the main Product Backlog (for reasons I can’t see) then don’t bother writing a User Story. Not everything in the Product Backlog needs to be or wants to be a User Story.
Story Take Two
Martin writes up an index card for the Foobar class and posts in the ‘Technical issues’ list. Since it’s close to lunchtime and everyone is already getting ready to leave, he grabs Kirby and Doug. They debate the priority compared to other issues and decide that upgrading the CI server to get faster builds is more important. They point out to Martin that “Foobar” is in a rarely-visited portion of the code.
Other sources:
“As a Developer is not a Story” – Bill Wake
“Technical Stories: We don’t need ‘em” – Ron Jeffries
“Refactoring not in the Backlog” – also Ron Jeffries
“Technical User Stories” Ariel Valentin
Scrum by Example is a narrative-style blog series designed to help people new to Scrum, especially new ScrumMasters. If you are new to the series, we recommend you check out the introduction to learn more about the series and discover other helpful articles.
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.
I like this post. I disagree with one of the points in the analysis, perhaps it is just the way it was written. In the analysis you say “User Stories must deliver real value to actual users.”. I believe that User Stories must deliver real business value. Much of the time that value will be to actual users.
Another form of business value is paying off technical debt. I believe that the product owner should at least have an understanding of how much they are paying for the technical debt reduction. I that the debt backlog that is prioritized and owned by development.
Another example of business value that extends beyond development is perhaps installing a wiki for writing and keeping documents for the organization. (Assuming a wiki has a justifiable business proposition that the business and PO buy into). This is something that has the potential to lean the organization which translates into value by saving writing time, increasing transparency, reducing errors, etc.
Glenn – I think you’re saying that some business value can be delivered in ways that aren’t directly tied to end users. Agreed in which case don’t use user stories for them.
If the Product Owner can make sense of the value and prioritize it great. In many cases they can’t make good prioritization decisions around these items.
If the wiki was for the benefit of the dev team I probably wouldn’t put it on the Product Backlog. If it was a greater good, I might.
What wouldn’t go there is the issue with the “Foobar class”.
Mark – sorry to open an old conversation but is pertinent to a conversation in my team at the moment.
Once you’ve made some allowance for tech stories how do you then generally balance the throughput of these vs business stories? i.e. that the ‘tax’ is roughly at the agreed level. Do you size these stories or manage through conversation and collaboration? (Or something else)
Obviously this is more likely to present a challenge when velocity is less than forecast or the team are faster but one or other seems to be getting a raw deal.
I think Paula changed her name to Jane in the middle of the conversation.
Good catch, 10yrs after I accidentally changed her name I fixed it. 🙂