‘Technical story’ may be an oxymoron, but so-called “technical stories” often contain the kernel of a valuable feature because developers often have good intuition about a product and how it can serve users better.
In this episode, Richard and Peter take on the challenge of so-called “technical stories,” backlog items that emerge from a development team and that don’t represent a clear slice of customer value. How should a product owner handle these? Are “technical stories” even a thing?
Episode Transcription
Richard Lawrence
Welcome to the Humanizing Work Mailbag, where we answer questions from the Humanizing Work Community!
Peter Green
If you have a question you’ve been noodling on, email us at mailbag@humanizingwork.com, and we’ll see if we’ve got a good answer for you.
Before we jump into today’s episode, just a quick reminder to rate and review the Humanizing Work Show in your podcast app, or if you’re watching on YouTube, please subscribe, like, and share today’s episode if you find it valuable to you. We appreciate your help in spreading these ideas.
All right, on to today’s question. It’s one that came up in our Product Owner Community of Practice. We’ll get to the question in a moment, but first, a quick note on our communities. We host three role-based communities of practice. One for ScrumMasters and coaches, one for Product Owners and similar product-focused roles, and one for leaders and managers. Each community meets once a month on a Zoom call to deep dive on a topic and stays in touch throughout the month in an online community. The Zoom calls are recorded, too, so community members have a library of past sessions they can dig into on a variety of topics. If you’ve been in one of our workshops, you’re eligible to join these communities. Contact us for the details.
Ok, back to the question: In this community session we were working through how to split gnarly, hard-to-split features and user stories. And Cindi, a longtime client and community member, brought up the topic of “technical stories” as a type of hard-to-split backlog item. In her context, these were backlog items that came from the development team, that probably really did need to be built, but that weren’t directly connected to or directly producing customer value. What should a Product Owner do with those?
Richard
First off, while I know what the term means, it seems to me that “technical story” is an oxymoron. In Agile software development, “story” is a shorthand for “user story”—that is, a change in system behavior from the perspective of a user. Teams adopted user stories as a way to avoid describing our work in terms of technical changes so we could better connect to user needs and business value. So, having the word “story” refer to a technical piece of work that won’t be user visible and won’t have direct user value feels a bit like cleaning up the food in your refrigerator, shutting the door, and then saying that you just made a meal. Calling it a “technical meal” still doesn’t change the meaning of the word “meal.
Peter
And with tools like Jira calling everything on a backlog a story regardless of its content, that horse has probably already left the barn; but we can’t really tackle this topic without a reminder about what user stories are actually all about.
Richard
OK, setting all that aside, how should a Product Owner handle these things? What should a Product Owner do with backlog items that come from their team members? I can think of two not-so-good options and one better option. And let’s go through each of those.
The first not-so-good option is to reject any items that don’t have clear business value. “If you want to get something on the backlog, it’s got to come to me with clear business value—otherwise it doesn’t make the cut.” This has the advantage of keeping your backlog really clean, I suppose, but there’s a cost. You devalue your team’s intuition about what’s important, you miss opportunities (because they probably are right sometimes), and you reduce engagement. It’s going to be frustrating for your team members when work that feels important to them never makes the cut.
The second not-so-good option is the opposite, which is “Just let it happen. The team thinks it’s important, so they’re probably right, so just let it go on the backlog the way they brought it up.” This one has a benefit in terms of the team feeling like they influenced the work, so they’ll probably be more motivated to do it; but it has the cost of you giving up your role to maximize the flow of value through your team; and you’re going to end up with partially implemented things in your product, because if this work isn’t a complete slice of business value, you’ve got something sitting there that doesn’t quite do the job, and is waiting for something else that needs to happen that you may not have prioritized the same way.
The third option, and I think the better one, is to treat your developers as stakeholders and work with them to find the business value of the things that they bring up. Assume their intuition is good and has something to it, and reverse engineer the value from there. Then, slice the resulting large item (because it’s probably larger than what you started with), as you would any other large item. Sometimes, by the way, that first slice is going to be a product assumption test. This has several benefits. You benefit from your team’s intuition; you engage them in the search for value; and you create alignment, even when their ideas ultimately don’t pan out, because you worked through it together. As an example, let’s say you collaborated to come up with a good test to see if they were right, and it turned out they weren’t. They were involved in designing that test, so they are going to be with you on the result.
The way you get potential business value from a technical idea is similar to how you work with any stakeholder who comes to you with a solution request that doesn’t have a clearly defined problem it solves: you ask “why” without asking “why.”
Here are a few examples: You might ask questions like, “What were you doing the last time you wished we had this in the product?” And “Once we have that in the product, what happens next? How will users know we’ve built this? What will they appreciate about it? What else would we need to build to really experience the value of this? What are we assuming if we prioritize this? How would we know if we were right about that? How would we discover if we were wrong?”
Questions like these should help you reverse engineer the user-facing business value implied by your dev’s intuition about technical solutions.
Peter
From there, it’s useful to help the developers understand how we think about value. For example, we help Product Owners model value by categorizing an idea according to its economic benefit. There are only four categories of economic benefit: An idea can increase revenue, it can protect revenue, it can reduce costs, or it can avoid costs. So helping the developers understand that there are four types of benefits, now they can start to frame things that way as they think about ideas. For example, a lot of technical things are going to reduce costs. That is an economic benefit. It could make them easier to maintain. It could reduce the number of defects that are showing up. Helping them understand that there is an important category of economic benefit there, helps them to make the case for why their intuition is right.
Then, the next thing we do with product owner is, since something in the backlog represents a prediction of value, not a fact yet, we like to clearly state our theory of impact: We build a thing, then something happens, then something else, etc., until we realize the economic benefit.
Richard
Getting really clear on those intermediate steps in our theory of impact helps us align on why we think the thing is important, which helps us prioritize it. It also helps us examine which parts of the theory are most risky so we can test the riskiest parts soonest, either by building a slice of value to test just that part of the theory, or by doing other types of validation testing to help us know whether we should invest in building something at all. Bringing developers along on this approach helps them tune their intuition, have a better understanding of how important something might be, and more effectively advocate for their ideas going forward.
“Technical story” may be an oxymoron, but so-called “technical stories” often contain the kernel of a valuable feature because developers often have good intuition about a product and how it can serve its users better.
Peter
Please like and share this episode if you found it useful, and keep the questions coming! We love digging into these tougher topics, so send them our way.
Last updated