How do you define your backlog when your team’s work involves refactoring or is architectural in nature?
At Rapid River we like to use Scrum. One thing we like about Scrum is the roles it places on software teams. The three key roles you’ll see on a Scrum team are:
We typically think of a Product Owner’s role on a Scrum team in the context of building a product for end-users. Users who are perhaps paying a subscription to use the product. Users who are not employees of the company who own the software.
The backlog the Product Owner defines is essentially a roadmap outlining the future features of the product being built. They do this by:
But what happens when the team’s focus is something different?
Another thing we like at Rapid River is to work on projects which are internally facing. Projects which involve refactoring or architectural evolution. For instance, migrating a database system from one technology to another, rearchitecting information flow within the product’s stack, or moving one business component from an in-house to a third-party solution.
How does the Product Owner role differ in this case? It turns out that it changes quite a bit. Let’s take a look at how.
The business domain becomes the technology stack in which the product is built. The Product Owner must understand the technology stack very well. Their role is therefore highly technical.
Describing the roadmap via design prototypes is often irrelevant. The scope of work will more likely be a series of refactorings. The project might depend on the choice of a key technology like a database system, data bus or analytics platform. The Product Owner needs to know this domain deeply and be able to make lasting business decisions based on this understanding.
Users of the software being created tend to be internal to the company which owns the product. More often than not they are technical people: developers on other teams, operations engineers, etc. If not technical, they may be members of sales teams, marketing people, customer support reps, data analysts, etc. These people are stakeholders. The Product Owner needs to communicate to these users using language they understand, again often technical in nature.
The Product Owner may need more input from the Development Team than they would otherwise. In order to figure out feasible and appropriate solutions, they may need the Development Team’s expertise. They may be a developer themselves, having stepped into the role for the duration of the project.
To excel in a role like this, a person will typically be good at:
Oftentimes a medium-sized software company may be missing this role and suffering as a result. The tech team’s Scrum teams may have Product Owners. Teams may be able to define user-facing roadmaps and implement them.
But when it comes technical debt repayment, refactoring or significant architectural changes, they stumble. Oddly defined initiatives (sometimes comprising of team of only developers, working apart from the way other teams work) get underway and eventually fizzle out.
What’s needed in these cases is a regular Scrum team with a Technical Product Owner.
Is technical debt bogging down your development effort? Do you suspect you need to repay that debt but aren’t sure how to get started? If you’d like to hire a team who can help (complete with a Technical Product Owner to boot) let’s start a conversation.