Why you need to plan operational work
Building a software product is more than just building new features. While greenfield projects might get away with pure feature development, that honeymoon is over as soon as real users get involved. From that day on, the team's attention needs to be spread over keeping the product running and adding new functionality.
One of the crucial parts of predictable long-term planning is making sure you plan room for operational work.
While devs are building a cool new feature, their users are reporting a weird, impactful edge case that needs to be tackled. There are complaints, errors, and maintenance work to handle. It feels like a conveyor belt pushes a never-ending stream of bugs, tweaks, and requests into the team's backlog. It's easy to get overwhelmed.
That's why greenfield is building software on easy mode. Without users, the team can focus on purely building rather than also juggling whatever falls off the conveyor belt. It really is a luxury if all we need to worry about is adding more features. Most teams don't have that luxury.
Live products need customer support and bug reports. A client might request an export of their data. A database might need to be upgraded, and a vulnerability might need to be patched. Developers must redesign architectural choices that have reached their limits. Technical debt should be repaid. Infrastructure needs to be improved, and better tools added to the stack.
All of this is vital work that's non-optional.
One could define operational work as all the work that's not creating new features. That's technically true. But there is an emotional component to it as well.
People get enthusiastic about building new features. It's often why they entered the field in the first place. Everyone, from CEOs to managers to developers, loves to dream about the product's future state.
Attend the average roadmapping session, and you'll see a room of people pretending there is only feature work in the team's future. Talk to a stakeholder, and they'll bring up The Next Big Thing but won't mention those boring server upgrades.
Yet the conveyor belt doesn't stop. Operational work is all the work that doesn't get the love it requires.
In that regard, we could define operational work as all the crucial work stakeholders don’t care about.
There is a catch, however. If we don’t give it our love, operational work has a way of grabbing our attention.
Given enough time, one of those neglected work items becomes urgent. We postponed that upgrade, and now one of our vendors no longer supports Java 11 for that crucial component. All of a sudden, we need to upgrade before January!
When it comes to priorities, there are three levels, and they are very familiar to all of us in the software space.
Level 1: Urgent operational work (Fire fighting that needs to happen now. Drop everything!)
Level 2: Feature work (What everyone really wants. We'll work on this as soon as the fires are out.)
Level 3: Regular operational work (One day? Whenever we find the time, you know.)
What stays on Level 3 for too long becomes Level 1 at some point. That's almost a law of nature. We don't care about upgrading dependencies until that security audit forces our hand. Then, it's our top priority.
While we build the stuff we want, the boring stuff no one cares about piles up until it catches fire.
That's why it's so important to plan for operational work. We need to dedicate Recovery Blocks so the team actually has time to process what rolls off the conveyor belt. Teams need to make sure operational work doesn't pile up.
Too many teams plan for 100% feature work yet spend most of their time firefighting. They schedule an easy sprint and wonder how they've got so little to show for after two weeks.
A team needs to spend between 25% and 75% of their time on operational work. Maintenance, bug fixing, upgrades, improvements, repaying technical debt. It depends on the team's size and the maturity of the product.
The plan should reflect that.
If your team is flooded with service requests and maintenance work, most of their time should be spent on Recovery Blocks. If we dedicate enough time to tackle what comes off the conveyor belt, we can limit the urgent fires.
Then, and only then, can we reliably carve out time to focus on the features we care about.