A struggle that software development teams have faced since time immemorial is the balance between feature development, bug fixing, technical debt, innovation, etc.  Under aggressive deadlines, it can be easy to fall into the trap of focusing almost full-time on feature development and then having to set aside weeks or months for full-time bug fixing, technical debt, and innovation in order to catch up, potentially causing stress for the team because of pressure to return to feature development.

After several experiences like this, I created a sprint planning framework for my team that cultivates continual progress toward feature development, product quality, innovation, tech debt, and other priorities in a sustainable way.  I originally referred to this as a 50%/20%/20%/10% split, but that doesn’t quite roll off the tongue and everyone loves a catchy name, so I’ll refer to this as the Golden Mean of Sprint Planning.  Wikipedia defines golden mean as:

The golden mean or golden middle way is the desirable middle between two extremes, one of excess and the other of deficiency.

In the case of software development, there are multiple extremes: full-time feature development, full-time quality, full-time innovation, full-time tech debt, etc.; we can’t have them all, and shifting from one extreme to another regularly is painful for the team, so we need a middle ground.  Also, while I call it the Golden Mean of Sprint Planning, it is not because it’s the end-all perfect plan but because it’s a suggestion to create a cadence that balances all of our areas of work sprint over sprint.

The Golden Mean of Sprint Planning is simply a division of each team member’s sprint bandwidth into four areas:

But wait!

You’re probably thinking, “How would we reduce feature development to 50% when we have deadlines to meet?”  For features that are in flight when attempting to implement this framework, there’s probably not much you can do and you’ll need to stick to your committed timelines and deliverables.  For new features, though, what we’ve done is break down the feature into stories, estimate the stories as if one developer would be working on them full-time (we also create a story to buffer two weeks for integrating with each new API endpoint we interact with as part of this feature), convert the total point count into a sprint total, and then double it.  When we provide this total estimate to product management, it almost always goes beyond whatever dates they had in mind for the feature.  However, this is expected and begins a conversation in which we do one or more of the following:

• Ship early: Use the original date as an alpha or beta milestone rather than a GA
• Ship less content: Reduce the scope of what is delivered on that date
• Ship fewer features: Reprioritize other features in-flight or incoming in order to increase staffing for this project and thus reduce the estimated sprint count
• Ship later: Push out the delivery date

One reason that standing our ground with our buffered estimations is important is that in many cases these hard-fast dates proposed by product management end up being moved later for reasons beyond the UI team’s capability to deliver on that date, such as due to other dependencies for the feature.  By sticking with our Golden Mean cadence, we ensure our team is consistently delivering quality, innovation, tech debt, and more regardless of how the feature development is going.

In Practice

The way we’ve been able to live out the Golden Mean of Sprint Planning has been during what I call our sprint pre-planning.  As is usual for most things planning-related, it begins with a table.  Here is an example of what this looks like for one of our sprints after we filled it out, and below it, I will go through the steps we took to figure out what to put where.

The week that a new sprint starts, I create a table in a wiki page that contains each team member’s name and columns for feature-related tasks; quality-related tasks; innovation, tech debt, etc. work; the number of days of on-call responsibilities; and any holidays or other reasons for time off.  With that table in place, I start by identifying who is on call for service outages and deployments during that time, and who has upcoming vacations or holidays, and fill in those columns accordingly.  Since ensuring that we have a 20% buffer each sprint for innovation, tech debt, etc. is one of the primary goals of this planning framework, I also fill in that column with any items related to those that I’ve already discussed with the team.  This initial pass gives a general understanding of the team’s bandwidth for the next sprint and ensures that innovation, tech debt, and other important tasks are already placed into the sprint first so that they are not sacrificed to the pressure of feature delivery and quality.

Next, I discuss with our team’s scrum master the prioritized work for the next sprint, whether it be features that are in flight, customer-raised bugs, quick wins, localization or accessibility tickets, etc.  This conversation is mainly to convey what needs to be triaged but without necessarily assigning names to the work just yet (however, in some cases, we know to whom it should go at this point).  As part of this, I provide a list of tickets and tasks to triage, and then our scrum master takes it from there to fill in the “Features” and “Quality” sections for the team.

Our scrum master first reaches out to each team member to ask what are the next tickets they need to address as part of the epics they own, and she adds them to the “Features” column.  Next, she goes through the list of tasks to triage, filling in the gaps in the “Features” column where team members either have less feature work than 50% of their sprint and adding the quality-related tasks to the “Quality” column.  If a team member doesn’t have a task for innovation, tech debt, etc., we roll that 20% into either feature development or quality as needed; ideally, this should be the exception, not the norm, and I continually encourage my team members to use that 20% buffer for an innovation or tech debt project that interests them or aligns with their career goals.  The day before our sprint planning meeting, we also check on any tasks from the current sprint which will carry over into the next and adjust the “Feature” and “Quality” items for those team members accordingly, either moving tickets into the next sprint or assigning them to other team members who have extra bandwidth.

One great side effect of this process is that it involves the team throughout the week in small conversations leading up to the sprint “planning” meeting such that we are able to use that meeting less for actual planning and more to go through and confirm the tasks assigned to the next sprint; everyone is mostly aware of what they’ll be working on going into that meeting other than any last-minute changes.  This has reduced our whole-team planning meetings from around 1 – 1.5 hours every two weeks to about half an hour.

The Test of Time

I first created and implemented the Golden Mean of Sprint Planning framework in August 2021 and have been using it for my team’s sprint planning for the past two years.  We’ve continued to ship features consistently on time (barring unique circumstances) and with quality.  The various product managers we’ve worked with were willing to negotiate the dates, scope, and staffing based on the 50% sprint allotment to feature development and have ultimately been happy with our ability to ship their features.  Best of all, the team was able to do some great things as part of our 20% buffer for innovation, tech debt, and more, such as:

• One team member prototyped the lineage of objects involved in data governance violations using a Sankey diagram to improve our original list-based, non-visual lineage.  Once the prototype was created, it was presented to product management for productization, added to our team’s roadmap (thus converting it from a 20% project to 50% feature development), and eventually released to customers.
• He also explored support for teams to create a micro-frontend for their “nouns” (the top-level navigation elements in our product and their associated pages) in order to split up a monolithic codebase into separate, more maintainable codebases, improving build times, simplifying test coverage, and decoupling deployment from other nouns.  This was presented to our organization’s architects and was eventually approved for developing the infrastructure more fully, again converting it from a 20% project to a 50% feature development project.  Several of our product’s “nouns” have been converted to micro-frontends already, with more on the way.
• As mentioned earlier in this post, one team member spent 20% of his sprint contributing a new component to our organization’s Ux pattern component library, ensuring it met the high visual, design, and accessibility standards required for that library.  This component will be used to retrofit several custom implementations already in the product for consistency and serve as the go-to standard for future features that need this pattern.
• Another great use of this 20% time has been for a team member to address tech debt “smells” as she encounters them.  For example, she has addressed a variety of console warnings that drowned out legitimate issues and has been cleaning up old feature flags (what we “turn on” to make a feature available for individual or all customers) in the codebase that have already been turned on for everyone but never removed.
• In some cases, we’ve used this 20% time for taking on more formal roles.  Our scrum master uses this 20% time to oversee the various Agile-related needs of the team, such as this pre-planning work described above.  Another team member serves as a Quality Engineer (QE) for the team, helping us create high-quality test plans, coordinating bug bashes, and investing in our integration test framework.  Finally, another team member, as mentioned before, used this 20% time to serve as a Ux product manager for our organization.  He worked with the full-time Ux product managers to develop the product requirement documents for several features, helping pave the way for several product-wide initiatives to move forward.

I will acknowledge that due to unique constraints or challenges, not all teams who learn about the Golden Mean of Sprint Planning may be able to put it into practice.  It requires supportive senior engineering leadership who understand the value of this balance even if it means fewer feature releases each quarter, and it is founded on strong relationships with product managers so that negotiations about timelines and deliverables can be productive.  I am very thankful for those at my company who have trusted me with implementing and using this framework for my team’s roadmap.

That said, I hope that the Golden Mean of Sprint Planning can be a valuable planning framework for you and your team and that your team can reap the benefits of continual progress across multiple fronts.  I wish you safe travels as you navigate the golden mean in your team’s journey forward!