Prioritizing Invisible Work
Scrum teams are supposed to be focused on delivering value to stakeholders, and we usually think of value as user-visible features. But there are also many less-visible elements of the process or code base that enable the team’s ability to deliver value. How you prioritize, plan, and implement that sort of work isn’t always obvious.
In the Scrum framework, the product owner is the person responsible for prioritizing the work. Anything you do, even technical work and infrastructure, should help deliver product value. The Scrum Guide explains that the product owner is responsible for maximizing the value of the product resulting from the development team’s work, so ensuring that the team is working in an efficient ecosystem is implicit. The product owner should be made aware of infrastructure and larger technical debt items.
But depending on the team and the product owner, enabling technical work sometimes gets deferred for too long.
Making all enabling work into fully formed product backlog items might get in the way of getting the work done. Technical debt and larger infrastructure work make sense as backlog items, but some work is just good engineering practice. For example, basic refactoring and cleaning things up as you are in the code—sometimes referred to as the Boy Scout Rule, because you are leaving the code better than you found it—could be considered part of the overhead of doing any work, as they improve the code but don’t change any functional or operational behavior.
There are also work items that will give the team an operational boost and perhaps avoid a crisis, but that never quite seem to make it to the top of the priority list. A team that so closely follows the framework of the product owner prioritizing the work might not ever actually do the work if it doesn’t hit top priority. If the work doesn’t prevent the team from delivering on its commitment or affect user-visible features, this approach is taking the role of product owner too literally.
For enabling work that is valuable but too large to be a priority, consider how it can be done incrementally. Present the vision to the product owner and explain how the team can make progress in small batches, perhaps while in the code base or if the team has free time. Build and deployment improvements often fall into this category, as do some tools and improved process automation work.
To deliver product value effectively, a Scrum team needs to work on both new features and on improving the agility of the infrastructure and code base. Sometimes that involves work that isn’t feature work.
Whether you plan all your work as stories, work to reduce a list of technical challenges as you visit the code, or break a larger technical change into smaller, noninvasive steps, infrastructure, technical debt, and performance optimizations are all part of delivering value efficiently.
