Does your team struggle to deliver sprints on time? Do you often have to split stories or determine what to do with major bugs at the end of a sprint?
The Structure of a Typical Sprint. When you understand the key activities within your sprint, you can choose a sprint length that increases the chance of consistent sprint success, with fewer bugs and fewer incomplete stories.
If so your issue may not be your process or your team but instead your sprint structure. Let’s look at this common issue in more detail. (Note: Going forward click on graphics to enlarge them).
How Did You Determine Your Sprint Length?
The current thought in the Agile community is sprint length should be somewhere between 1 and 4 weeks.
Many teams pick a sprint length based on what other teams or companies are doing, or based on a length their instructor suggested during Scrum training. We often choose a length quickly because we want to get started using Agile as soon as we can.
I believe you should be more thoughtful on deciding your sprint length, as the sprint length is at the foundation of your entire Agile process.
Let’s look at ways you can choose a sprint length that will increase your chances of delivering sprints successfully on a continuous basis.
Start By Remembering What We Are Trying to Accomplish with Sprints
You are probably well versed on what sprints are and why we do them, but here is a quick review on sprint basics and how we use them to determine sprint length.
To help you determine how long you will need for a sprint, define what sprint complete, or done, will mean. Teams often keep the definition of done on a team room wall.
Sprints deliver a potentially shippable increment of software every few weeks. This does not mean every sprint has to be deployed to your production environment, but the stories should not be missing anything to make them production worthy. “Production worthy” often means:
- Story is complete
- Story passes unit tests
- Story passes functional tests
- Customer approved the story
- Story passes non-functional tests (e.g. performance, security)
- Story integrates with the existing code base
- Supporting documentation is complete
How long does it typically take your team to get a subset of stories to this level of completeness? This is your first clue as to how long your sprints should be.
How Long Will You Need for Sprint Planning (at the start)?
Perhaps the most overlooked part of sprints is sprint planning. Agile teams often rush to start a sprint even when the goals are unclear. We do sprint planning because the goal is not to start a sprint as soon as we can, but rather to finish a sprint as soon as we can.
I often find that teams do high level story point estimation and load their sprints based on how many story points they average per sprint.
In my opinion story points only tell us which stories go into sprint planning. During sprint planning the team will break down the work to the point of understanding what each functional area or individual has to do at the task/hour level. You should allocate enough time to plan your sprint with confidence as opposed to trying to start coding as soon as you can.
It typically takes 1 to 2 days to understand the work well enough to commit with confidence. Your sprint length should include the time needed to plan the sprint effectively. [Note that many companies I work with consider sprint planning to be a non-value add activity. In reality this portion of a sprint may be more important than the coding and testing. This activity ensures we are clear on what the customer needs before we begin and commit to construction.]
How Long Will You Need for Sprint Adapting (at the end)?
Most teams need 1 to 2 days to wrap up a sprint at the end. Wrapping up often includes:
- A demonstration to the customer or subject matter experts
Determine how much time you need to wrap-up at sprint at the end, and include this time in determining your length.
- A review of sprint deliverables and project status with key stakeholders and executives
- A review of the team throughput (velocity) for the sprint
- A review of new stories that were discovered during the sprint
- A review of stories that did not get completed during the sprint
- A review of open bugs from the sprint
If your projects or releases are not too complex, for example if you are mainly delivering enhancements to an existing platform, the adapting practices can often be completed in 1 to 2 days. On complex projects that span time zones or larger teams, sprint adapting and reviewing can run from 2 to 4 days. Adapting is considered part of a sprint so make sure your sprint length includes reasonable time for these activities.
Other Items to Consider When Determining Your Sprint Length and Structure
I often use the table below to help clients choose an initial sprint length. Note that I say initial because your first sprint will be your best indicator of whether you have chosen the correct length. If you struggle to deliver production ready code you have probably chosen a length that is too short. This is the most common issue I see with clients.
Use These Questions to Help You Determine the Length and Structure of Your Sprints. Click to enlarge.
The Final Product
When you have completed the steps above you should end up with a sprint structure like the one below. The structure will be dialed into a sprint length and sprint activities that set your team up for success.
Example Sprint Structure
Feel free to contact me if you would like guidance on establishing your sprint length and structure.