TLDR: It depends!
Sprints are the heart of any agile product development team, but many product teams struggle to find the right sprint length to satisfy all stakeholders. In my experience with dozens of agile development teams building software products of all shapes and sizes, I’ve yet to find the perfect answer that works for every team.
Continuous experimentation and adaptation from sprint to sprint will naturally identify the right cadence, and the team will quickly settle into a rhythm of releases and feedback iterations with their users. Frequent retrospectives and the flexibility to adapt to changing conditions will prevent a natural groove from becoming a rut.
The Agile Manifesto
As you think about sprint planning and establishing a team cadence for the review, planning and release cycle of agile software development, here are three related principles from The Agile Manifesto to keep in mind:
- The highest priority is to satisfy the customer through early and continuous delivery of valuable software
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale
- Working software is the primary measure of success
The 2-week Sprint
At DataSeer, we work in two-week sprints and release software into our production environments at least once per sprint. After trying various sprint lengths, formats and processes, we found that a two-week duration is our sweet spot. Our sprints typically start on Monday and end the following Thursday (a duration of 9 business days). This includes release candidate testing in our staging environment in the second week before the software release on Thursday evening.
The illustration is below for reference only (where P = Planning, Dev = Development, RC = Release Candidate); testing is integrated, and we aren’t sprinting EVERY weekend.
The shorter schedule allows us to:
- Deliver customer value quickly
- Keep a well groomed backlog of user stories that are broken down into tasks achievable within a sprint
- Greatly reduce the risk of wasted effort before receiving user feedback
In addition to this schedule, we’ve also incorporated key enablers like our test automation and deployment pipeline, clear and consistent communication to stay ahead of roadblocks, and overall team empowerment. Of course, we still bust a sprint from time to time but always make time to reflect in retrospectives and adjust in the next week.
Refining, Adjusting & Keeping on Track
In team planning sessions and retrospectives, we periodically revisit the following questions which can drive adjustments to our sprint length.
- How fast can we deliver today if things are “ready to ship”? Seeking this answer will drive an ops discussion around CI/CD, which includes infrastructure and processes.
- Does our current sprint length allow enough time for testing and quality control? No one likes the pressure of a rushed release, especially the customer that finds your software bugs for you. One of the metrics we monitor here is the number of bugs in production or escape rate.
- Does our current sprint length allow enough time for delivery of customer value? Feature testing, incremental improvements and bug fixes all count!
- Is our release ratio of new feature development, bug fixes, existing feature improvements and technical debt payback weighted appropriately? Over-indexing on new feature development never works out, trust me.
- Are our customers happy, engaged and feeling like the product is rapidly progressing? NPS surveys, user analytics, and customer feedback reviews are all helpful in getting to this answer.
Finding the right sprint length for your product team requires experimentation, adaptation and patience. Armed with core principles and the right tools, you’ll be able to find the right cadence that balances out customer needs, released software quality and your team’s overall well being.
Some of my favorite reads on agility, sprinting and continuous delivery (AMZN links):