By The Readers Issue # 103 - The Sprint Plan - 2, 6, or 8
S01E03 - Going agile, one of the first things that teams do is deploy the 2wk sprint cycle. If you aren't sprinting every 2wks, are you really agile'ing? So, what is an effective sprint length?
Howdy Tribe -
Today's newsletter is going out to 195 dedicated readers.
Continuing with the series on answering questions from the readers.
(Dec 1) Lessons On Stakeholder Management For Large Cross-Functional Projects
(Dec 8) Psychology of Project Management: Leading Without Authority
(Dec 22) Power of Tribes - How To Build An Internal Network
(Dec 29) Challenges of Building In BigTech
Welcome to Building Romes Newsletter - By The Readers Issue, Season no. 1 Essay 3 🎉
Essay
What problem are we solving today?
Congratulations! Your team is growing because the company is making bank and climbing high. Wohoo! 🥳
You use to ship whenever you were ready when it was just the 3 of you but, now you are 4 teams of 6 with ownership of different pieces of the system, product managers, maybe Test Engineers, the full works.
You want to continue to ship software fast so you do what everyone does - implement agile.
Your go-to is the scrum approach. Your team is excited however, they want to know the answer to a very simple yet critical question: how long should your sprints be?
Lesson Learned and A Solution
Sprints are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint.
Source: Scrum Guide
Sprints are at the heart of scrum agile methodology.
The most common sprint length you see in the wild is 2wks.
Why? It is appears to fit the bill for many teams for rapid software development and release, faster demos, and shorter feedback cycles.
In many organizations, sticking to this 2 weeks sprint cycle becomes almost a mandate/mantra/dogma to maintain the agile org status.
But, is 2wks really the ideal sprint cycle? No. There are better options.
Lets take a look at some different sprint styles that I believe are more effective than the 2wk sprint.
Questions to consider when picking sprint length
Can I achieve meaningful output by the end of the sprint?
Is there room for discovery, rework, iteration or handling unexpected difficult to diagnose bugs?
How much overhead - engineering and product - will be required to manage the sprints back to back?
Is testing and validation part or post sprint? If former, do I have time to do that with the given length?
Sprint Lengths - 2, 6, 8
2 Weeks
In a 2wk sprint, there is no slack for additional discovery work or potential reworks. If you encounter a difficult task or bug that needs ton of investigation time or difficult to reproduce catastrophic issues (think: race conditions), you end up spending majority of the sprint on that.
That inevitably means at the end of the sprint most unfinished tasks will be pushed to the next sprint, which results in a cascading effect on later sprints.
The back to back nature of the sprints leaves little time for thoughtfulness from developers, adds pressure on Product Owners and Project Managers to not slip feature timelines which inevitably leads to teams making compromises in the project to meet deadlines.
Of course, we have to find time within those 2wks or right after to do the next sprint planning. This requires careful and thoughtful discussions between Product, Engineering, Design etc.
As you can see, 2wks quickly becomes… exhausting.
6 Weeks
The Google Dart team runs on a 6wk sprint cycle.
They started with a quarterly sprint approach but realized that drift tends to settle in on such lengthy periods of development time.
There are also perception issues. Since Dart is an open source project, one measure on the health of the project is how frequently are new features shipping. Shipping features 4x in a year versus roughly 8x in a 6wk sprint is a much better signal to the developer community.
With a 6wk cycle you have enough time to spend on
Discovery
Investigate difficult bugs
Ship bug fixes
work On large features
Allow product enough time to strategize on the feature backlog
8 Weeks
At Apple, iOS and macOS development occurs over 4 sprints, 8wks long with 6wks of development followed by 2wks of convergence which is also when sprint demos occur. Each sprint has a 1wk gap for replanning.
There are certain rules for the convergence period.
The goal for this period is test and fix bugs found for the work done during the development phase.
Write unit & integration tests
Refactor code for performance and elegance.
No feature work is allowed during this time.
At the same time, given how many features are typically in flight for a massive release like an Operating System, Project and Engineering teams can spend time to evaluate the remaining feature work and develop strategies for replanning.
The 1wk gap between sprints is when Craig Federighi and his Senior Leadership Team review all active feature developments and make strategic executive decisions such as date slips, re-architecture of engineering designs, UI reviews, etc. It also allows the engineering teams to come up for air before diving back down for the next sprint.
After the 4 sprints comes the multi-month convergence effort to get iOS and macOS from WWDC to shipping in September with developer and user beta drops peppered every few weeks.
Final Thoughts
The 2wk sprint is at best an illusion. It works if you own a very small component of a larger machinery or shipping fixes for quality issues. However, when it comes to feature development which can take multiple weeks, a 2wk sprint approach just means that the largest work breakdown size acceptable for a given task is 2wks.
In my experience for product driven organizations that are shipping new features on a regular cadence, switching over to scrum approach or agile, a 6 or 8wk sprint is much better OR better yet, my recommendation is to do what works for your teams and the work you are doing. You are still agile even with sprints sizes larger than 2wks.
For example, if a feature you are working on is going to take 6wks of development time, in a 2wk sprint approach that is 3 sprints to complete the work versus a 1 sprint in a 6wk approach.
But, we ship features faster in a 2wk sprint. Actually, no, you’re not shipping features faster, you are just pushing code out the door faster. That is not the same. A feature is shipped when all the code is finished. But, the negative psychological pressure and logistical overhead of a 2wk sprint cycle creates an unnecessary burden and will force, in many cases, engineering teams to find the shortest path, full of shortcuts, instead of the right way to do the work. You don’t plan to compromise but when the sprints are running out and there is ton of work to be done that is what ends up happening.
Try this exercise with your team next time: If you’re team is running on 2wk sprints, evaluate what is your ratio sprint over sprint for tasks planned versus tasks completed for features that require multiple sprints.
Do you find that you end up doing the most meaningful and impactful work at the later end sprints?
What about time spent on testing and room for re-evaluating the design approach?
Do Product Owners have enough time to thoughtfully evaluate the work in the backlog?
Now, experiment with a 6wk sprint and see if you notice a difference.
I will also deviate from the scrum process and say that you need a break between sprints. Engineering teams need time to breath, shake out the arms, and clear the mind before diving right back into the next sprint. How long that gap is depends on your team appetite.
Until next time! 👋
-Aadil
Was it useful? Relevant? Help me to improve!
Was this edition useful? Relevant? Pointless? Help me to improve!
