Technical Product Ownership

I hear this challenge over and over again from Product Owners. They have little to no problem writing functional user stories, but then…

Bob, the team is placing tremendous pressure on me to write technology centric User Stories. For example, stories focused on refactoring, or architectural evolution, or even bug fixing. While I’d love to do it, every time I give them to the team and we discuss them, they nit-pick the contents and simply push back saying they can’t estimate them in their current state.

So I’m stuck in a vicious cycle of rinse & repeat until the team gets frustrated and pulls an ill-defined story into a sprint. And this normally “blows up” the sprint. What can I do?

I think the root cause of this problem is that the company views the Product Owner role as the final arbiter of user stories; meaning they need to write them all. I feel that’s an anti-pattern, but the question remains, what to do in this situation.

I’ve seen several clients apply approaches that significantly helped in handling, what I refer to here, as technical user stories. Let me share a couple of real-world stories (nor user stories mind you 😉 that should help you envision some alternatives.

Two Stories

Creating a Role of Technical Product Owner

Around 2008 I was working with a client who had developed a SaaS product offering on the Microsoft .Net stack. However, they had used an open source database for some of their core functionality in addition to SQLServer for the majority. The open source database started suffering from increased performance degradation over time and the engineering team decided it was time to replace it and normalize everything to SQLServer.

While this was a sound business and technical decision, the work definition, design and planning needed to be executed within the Scrum framework that the organization had been using for several years. On the surface that wasn’t a problem, but it was a rather large-scale infrastructural project and the product organization and teams hadn’t tackled something like that yet within Scrum.

The other problem was that this was a highly technical project and the teams’ Product Owner was not technical. They came up with the approach of creating a Technical Product Owner and selected one of the development managers to fill the role.

This role was a “strong partner” with the Functional Product Owner for the team. Over time, they began to draw a distinction between the Technical Product Owner and the Functional Product Owner in discussions and work focus.

They setup some rules for the two to collaborate on the same set of Backlogs as they directed work towards their team(s):

• The Functional Product Owner was the primary PO for the team;
• The Technical PO was in an advisory or assistant capacity;
• Both PO’s needed to understand “the other side” of the backlog so they could easily represent the overall workflow, investment decision-making, and back each other up;
• At a release planning level, they would guide their backlogs and teams towards the agreed upon percentages of investment for functional vs. technical change;
• They would each address questions for their stories during the releases’ sprints;
• They would sign-off on their own stories; often the Definition of Done was different between Functional and Technical stories.

I vividly recall how wonderfully the two Product Owners collaborated on the project. I think that’s important for creating this “dual-role” and having it work. There needs to be professionalism, trust, and respect across the two. I liken it to a really strong partnership in order for the results to be balanced and so the team sees a “consistent & united front” with respect to backlog priority.

It took approximately 3-4 months for the database replacement project to complete. After that, the Technical Product Owner reverted to his old role. But as an organization, this notion continued for larger-scale, technically focused work, even if it was only a small set of stories. They typically made software functional managers or architects into Technical Product Owners when the need arose, which seemed to generally make sense.

Including Architecture and Sound Design

Another client was focused on developing a SaaS eMail application. They had about 10 Scrum teams working in parallel across the applications’ code base, which was based on the LAMP stack. Organizationally, they had a small group of UX engineers who were guiding the functional evolution of the product. In fact, at the time they were “re-facing” the product and trying to simplify and update the user experience.

Their customer base was growing quite rapidly, so they were experiencing performance issues as the architecture was stretched beyond its limits. This created tension to inject both the UX redesign efforts and foundational architectural upgrades across the teams Product Backlogs.

The client CTO was also the head of a small group of architects. He was struggling in how to ‘guide’ architecture across 10 teams in a consistent way, while integrating with the overall company product road-maps. He initially tried doing that by simple influence; getting involved with the teams and informally asking them to take on architectural tasks. However, he became frustrated when the tasks were inconsistently delivered and deployed. Most often there was a lack of cohesion and integration as architectural elements were implemented across teams.

He finally struck on a recipe that seemed to work. He took on the role of Chief Technical Product Owner. He consolidated all of their technical work intentions, both from a software architecture, test architecture, and UX design perspective, and placed them on a single technical backlog. He and his team members worked hard to write solid stories, break them down (with the development teams) and stage them in the right technical flow (priority order). He considered x-team dependencies and deployment efforts as part of it as well.

Another important part of his strategy was to guide what I’ll call “look ahead” within the teams. This was largely done by creating the right number of User Story Research Spikes and scheduling them appropriately so that the designers and architects could work with the teams on research & prototyping. The scheduling of this was critical, not too early and not too late, so as to not derail the clients’ functional commitments on the roadmap.

Then he met with our Chief Product Owner and her team of functional Product Owners, and integrated the technical product backlog with the functional or business facing product backlog. They did this at a roadmap level and also at an individual team backlog level. Over time they refined this approach and it worked quite well. The teams received a backlog that was ‘balanced’ across the architecture, design, and functional perspectives. If they had technical questions or needed help, they would engage the architects. The architects also shared in the “acceptance” of the stories, but it was considerably less formal than the first story I shared.

Technical Product Ownership (TPO)

Clearly in these two stories, there evolved notions of technical product ownership. In the end, it truly doesn’t matter if the TPO is a partner or external adviser. What’s important is that the “Voice of” architecture, design and technical flow is well represented towards the team via product road-maps and individual backlogs.

Informal TPO

There are probably two categories of this. First is, you have a smattering of technical stories needed within a product backlog and someone needs to help the Product Owner define, manage, and accept them. In these cases, I think just asking someone on the team to serve an informal (TPO) role is a fair and reasonable response.

They would partner with the PO and consolidate the backlog together. The TPO would lead grooming and maturation of the technical stories and the PO would manage the rest.

Formal TPO

This is an extension to the first case. I usually find it needed if there are large-scale technical initiatives in play OR a consistent flow of architectural stories trying to make it into the products’ evolution. Usually this would be for “older” products and the flow is related to accrued Technical Debt. In either case, there are more technical stories flowing through the team/backlog, which need consistent time and attention.

Chief Technical Product Owner

And for more organizational-wide guidance, the second story introduced the notion of UX and/or architecture group heads taking on the role of road-mapping architecture and design areas via user stories on product backlogs. This creates virtually two backlogs, that is a functional product backlog and a technical product backlog, that then need to be strategically merged into a single, thoughtful whole.

In this case, the two product views are merged and then ‘fed’ into their respective teams. The key here is the grooming process that surfaces dependencies and research spike needs so that the integration of the two and the execution dynamics are thoughtfully planned.

It’s vitally important that the teams themselves are involved in this process as soon as possible. Usually this happens when executing the spikes and via Release Planning meetings/activity. But each leader also needs to share their high-level strategies and goals with the teams on a periodic basis as well.

Wrapping Up

One of the largest challenges associated with Technical Product Ownership isn’t really technology-driven. It’s the tension between the business wanting to get as much functionality in the product as quickly as possible versus the need for technical debt reduction and technical evolution within the product. And how do I say this politely—usually the functional-side wins, which drives more and more technical debt and more pressure for improvement from that side.

So the Technical Product Owner needs to be someone who is balanced, who’s recommendations are trusted by all sides of the organization, and who can communicate the WHY behind the technology evolution strategies.

They also need to be able to “partner” with their Functional Product Owner partners. Indeed, they must acknowledge that the functional-side is always in the “drivers seat”. As there can be ONLY ONE Product Owner per team.

I’m incredibly interested if any readers have similar experiences to share in how they’ve handled “technically heavy” work in product backlogs. Please add your stories and approaches as comments.

As always, thanks for listening,
Bob.

Don’t forget to leave your comments below.