Who Fills the Sprint? My 45/45/10 Split
Posted on
Every project has way more things to do than resources allotted. That is a given for pretty much any human endeavor. Figuring out what to work on is the interesting part.
When it comes to software development, most companies plan work in time-boxed ranges, often called sprints.1 Let’s generalize and say two teams are contributing to this work: the business/product owners and the engineering team. Each has its own interests.
The business/product owners are usually focused on features and enhancements that grow the business. Sometimes these are time-sensitive, to meet a contract requirement, hit an annual cycle for customers, or keep a promise made to company ownership. If you are a young company, you might still be trying to prove the business is viable on a limited runway.
The engineering team owns the work of bringing that vision to life through code. They also carry a set of assumed responsibilities. Building construction requires fire suppression. Doctors order routine lab work to assess their patients’ health. Engineers are professionals in the same way, with unspoken work that must happen to deliver a safe and healthy environment. Some examples: maintaining verified backup systems, watching production for errors and anomalies, triaging those findings into future work and fixes, updating software to close known security vulnerabilities, and keeping a software stack that is, for lack of a better word, good.
Keeping everyone happy (or at least less frustrated)
When you plan your sprints, you need to keep these two teams in balance.
Let the business/product owners dictate it all, and you may validate the business idea or sign that new contract, but you are left with an unstable mess of software. That leads to customer and employee churn, or worse, people talking on social media about your platform downtime and security breaches.
Let the engineers have too big a say, and you can end up with overengineered features no one uses, or great uptime for a user count that does not sustain the business.
The other people who need some influence are the individuals who make up these teams. They each have their own itches to scratch. Giving them room to work on what they think is important, even if it moves slowly across multiple sprints, feeds their sense of autonomy and their satisfaction at work.
The company (hopefully) hired these people not as nameless workers, but as distinct and diverse contributors who bring a personal perspective in addition to their raw execution. If that is true, you need to give them some sun and space to grow.
Percentages
Here is how I think about it: 45% of the planned work comes from the business/product owners, 45% from the engineering team, and 10% from individual autonomy. Those numbers can and will shift over time, but that is the average I’d aim for in the long run.2
I’d be curious to hear how your own team plans its work. Let me know.
-
There is a particular frustration in asking your team to sprint endlessly. The word means “run at full speed over a short distance.” You can’t run full speed for the entire race. Also, this is not a race; the work never ends. ↩︎
-
Worth noting: I am biased as someone who prefers engineering-led businesses. I’m sure there are plenty of “successful” MBAs who would give the engineering team a much lower percentage and still find “success”. ↩︎
You might also like
About the Author. Mike Zornek is a developer and teacher focusing on product design and development with a heavy focus on Elixir and LiveView. In between his projects, Mike helps other teams through consulting. During off hours, he enjoyed watching Phillies baseball and playing relaxing video games.
Hopefully, you found interest in my scribbles. If you have commentary or a response, I'd love to hear it.