Allocating sprint capacity across features, platform, bugs, and ops
A strategy to plan a healthy balance of product & engineering work for your teams
Every company I’ve worked at/with has struggled to prioritize engineering work against product work. Most of them have tried to solve this by dedicating a percentage of their engineering capacity on engineering work. If done right, allocating capacity across categories provides a feedback loop that can provide insight into your team’s work and will help steer your team towards healthy collaboration with product. The goal is to align on product-engineering roadmap, which may or may not end up using a framework like this.
Categories
First, let’s define a few categories of work.
Innovation
Work categorized as innovation are high-risk, high-reward and have a low chance of success. Innovation is necessary to avoid the local maxima problem, otherwise you may just be adding diminishing marginal gains to your product. This category is a privilege; the ability to innovate demonstrates the level of your product’s maturity.
Feature
A feature is generally any work requested by a product manager or stakeholder.
Platform
Platform work is either:
- Creating capabilities to enable Features and create Innovation
- Reducing Operational overhead
Platform work is an investment into the product to make it more flexible, adaptable, maintainable, scalable, etc. Although it is engineering-driven, it provides opaque benefits to the end user and to the business. It is the responsibility of engineering to clarify these benefits to stakeholders.
Operations
Operations work is necessary toil to keep the business running. Generally, operations work should either not exist or be automated. Examples include:
- Bugs
- Engineering Operations such as manual migrations
- DevOps such as manual deployments and manual QA
- Outages and Incident Management
- Business Operations such as business logic changes
These operational tasks are mutually exclusive from the other categories. Some of these operational items are intentional (e.g. MVP-launch of a product that has not been automated yet). Others may be caused by a lack of user stories (e.g. from features) or from incorrectly implemented services. Operations is not owned by either product or engineering—it is a common enemy of both.
Innovation/Features/Platform Categories are not Mutually Exclusive
Don’t struggle to categorize work—categorization is just a framework to discuss how to plan work. Deliberating on the correct category for a work item is not going to improve the output of the work item. Create some simple heuristics to quickly categorize work. For example, if it’s product-driven, define it as a feature; if it’s engineering-driven, define it as platform work. Feel free to create new categories and break categories up.
Define an Ideal Allocation
Work with your product managers to define the ideal allocation of work depending on the maturity of your product. Here’s an example of an ideal allocation:
- Innovation: 10%
- Feature: 60%
- Platform: 30%
- Ops: 0%
You will never reach the ideal allocation, but it’s important to align on the goals such as: create a healthy product, increase velocity, and minimize operational overhead.
Create a Feedback Loop
Once you’ve align on the goals, it’s time to create a feedback loop.
Measure
After every planning period (e.g. quarterly), measure the work allocation. In JIRA, you can export your team’s completed tasks for the last few sprints to a Google spreadsheet, then categorize and visualize within the spreadsheet.
Reflect
Reflect on the work allocation in your last planning period. Here are some questions you may ask your team:
- What was surprising about the work this period?
- What can product and engineering agree on for the next planning period?
- What do we need to automate to improve velocity?
- How does this work allocation affect morale? Was there too much toil?
Adjust
After reflecting, agree on some action items for your teams. Some action items could be:
- Have product and engineering collaborate for causes of the bugs
- Prioritize and limit the intake of operational requests from stakeholders
- Add some platform initiatives to reduce engineering operations
- Advocate for increased engineering capacity
Plan
When planning for the next period, only cap how much of each category you’ll dedicate. For example, if your team completes 100 story points every period, only plan up to 60 story points for features, 30 for platform, and leave the remaining 10 for potential operational tasks.
Repeat
As you repeat this cycle, you’ll hopefully reach product-engineering alignment.
The Process is for the Goal
Remember that this process only exists to reach the goal of product-engineering alignment. If you already have alignment, then you probably don’t need this framework at all (although the graphs would be a nice visualization regardless). For example, one of my teams is working on a PHP to React microfrontend migration, which we don’t even categorize as platform or feature—instead, we try to minimize unrelated feature and operational work.
