Of all the seemingly critical questions facing a team about to plunge headlong into a Scrum implementation, this is one that should be approached with some caution: “How long should your sprint be?
The original literature from 10-20 years ago often states four weeks or one month. More recent literature often states 2 weeks, some enthusiasts insist on 1 week. So how do you decide what’s right for your team and your project?
The fact is, there are many reasons to pursue a short sprints, and there are many obstacles to the intimidating 1-week scenario. Since the trend is towards shorter sprints, let’s first look at the benefits of this goal.
A sprint is a feedback loop. An Agile Sprint is usually 1 week to 1 month. The cadence should be constant from sprint to sprint for a given team. However, sprints cadence can vary from team to team.
The shorter the sprint, the better – sprints are meant to put pressure on teams to innovate and deliver faster. Don’t overthink the length of your sprints; choose a 1, 2, 3- or 4-week cadence. Then adjust the sprint duration as you become familiar with the project or product.
Why 1 to 2 weeks?
Although scrum.org claims “one month or less”, there is a growing consensus that shorter sprints are better:
The shorter the Sprints, the faster feedback from clients and the market comes. The inner feelings of the team members also surface more quickly.
Sprints were designed to be short to break silos and deal with turf wars. How? Short sprints support cross-functional teams without external dependencies. Otherwise, the teams would not be efficient enough to complete the work within 7 to 14 days.
Newly formed teams reach their full performance within a certain number of sprints, either 1-week or 4-week sprints. In fact, longer sprints even increase the number of sprints teams need to reach their full potential.
When story points rather than time units are used to estimate tasks, short sprints allow teams to learn their speed sooner.
These tips apply to the fixed-length time frames of other agile project and portfolio management frameworks. For example, SAFE recommends that an iteration last two weeks1. Read Sprint vs. cadence vs. iterations.
Interestingly, software teams rarely choose 1-week sprints. Instead, two-week sprints are the norm. This has to do with the “architectural challenges” of software development and with stakeholders not always participating in Sprint Reviews. Another counterintuitive truth about sprint length is this: those new to agile should stick to shorter sprints – ideally 1 week.
What signs indicate a sprints cadence that is too short or too long?
Sprint is too short
Teams fail to create submitted user stories within a Sprint. It takes several sprints to get a proper outcome.
Sprint planning, revisions and retrospectives are superficial, trivial, a mere formality.
Breaks between sprints or mock sprints seem necessary. Although there are 1-week Ship-It sprints here at Big Picture, while 2-week sprints are the norm.)
Sprint is too long
Teams “accelerate” as the Sprint nears its end.
Teams have difficulty completing their planned work.
The project is so short that it cannot accommodate 6 sprints. Six is the minimum number of sprints to ensure sufficient feedback
Your competitors’ teams use shorter sprints than your organization.
Request routing is faster than the sprint length can accommodate (bugs to fix popping up, emergencies, etc.).
“Mini Waterfalls” will appear with a certain number of days planned for each
The big picture
While these are fairly objective indicators, it’s also good to be aware of bias. Teams will generally favor long sprints for convenience, while it is in management’s best interest to have shorter sprints to identify bottlenecks earlier.
Also, industries with stable requirements and established technologies will escape longer sprints.
Does it sound like you need to regularly check the length of your Sprints? Nothing could be further from the truth. Sprint length checking should happen randomly if at all, as it resets tracking at the initiative level. Speed Invalidity; forecasting and planning future sprints starts from scratch; teams escape performance indicators for some time.3
How to fit in 1-2 weekly sprints?
Practice breaking down the user stories in your backlog into fairly small tasks and sub-tasks.
Re plan during the sprint. Fill the Sprint to 50-60% capacity initially and add the rest later.
Note that the end of the Sprints is not the deadline. Rather, it is an opportunity to pause, reflect, learn and improve.
SPRINT PLANNING FOR SCHEDULED VS. UNSCHEDULED WORK
Before starting sprint planning, it is essential to define what you want to achieve during that sprint. Instead of using overarching strategic goals to guide your team, sprint goals should be smaller, more achievable chunks of work that can be completed in a shorter time frame.
If you are an agile Scrum team with high variability in your work, longer sprints can give you the margin you need to get the work done. If you have a 1-week sprint (with 1 out of 5 days already dedicated to ceremonies), even one or two random pieces of work can prevent your team from completing the work within the scope.
On the other hand, if the team has unplanned work with a lower level of urgency, shorter Scrum sprints lengths allow you to fit the work into Scrum sprint planning in a shorter period.
When it comes to how best to manage work, Jira is a great tool to help teams achieve this. Here’s a guide to starting, managing and completing a sprints using Jira.
TIME DEDICATED TO SCRUM CEREMONIALS
How much time per week should sprint planning spend on scrums, retrospectives, backlog editing, and demos? Shorter sprints mean more time spent in these meetings. This becomes even more important if you don’t have dedicated roles (scrum master, product owner).
What we see in weekly sprints is that teams can lose an entire day (twenty percent of the sprint!) of each sprint to demos, retros, and planning. So the shorter your agile scrum sprints are, the more often you have these ceremonies.
SIZE AND SCOPE OF TASKS
Is your work small enough to be completed in the length of the sprints? For example, if you often don’t finish work in 1 sprint, a longer scrum sprints might make sense (or you might need to work on improving the right size of your tasks).
FEEDBACK CYCLE
How often do I want to see and rate completed work? Is it acceptable to go 4 weeks without showing the work being done? Do you need to know every week? Sprint length determines how often you’ll see sprint previews and full sprint retrospectives
CONTROL AND ADJUSTMENT
There is no one-size-fits-all answer to the optimal length of a scrum, and iteration is the key to scrum – so don’t worry if your first choice doesn’t work for your team. That’s what your retrospectives are for!
Reference
https://staragile.com/blog/sprint-length-in-scrum