Five Factors that Guide Sprint Length Selection

Selecting the Optimal Sprint Length for Medical Software Development

Agile development methodology relies on a succession of “sprints”. Each sprint contains the next wave of critical components to be developed, tested, and released to the stakeholders. In a practical sense, sprints should not be spaced too close together nor too far apart in order to maximize development efficiency. In this blog, Rose Marcantonio, Director of Quality and Process (and Certified Scrum Master in her own right), discusses how to select the “optimal” length.

Having been a Scrum Master for many client projects, I have observed that sprint lengths seem to be subjective; different teams have their own preferences for their own reasons. The experts indicate that sprints ranging from 1- to 4-weeks are optimal, with a preference for shorter sprints. However, short sprints do not work for every project. For a project to be successful and meet all of its goals, one particular sprint length may be more optimal than another. Let’s talk about the factors that affect choosing a sprint length.

It comes down to these…

1. Uncertainty

Uncertainty can come in a variety of forms: Requirements are not well defined; technology is new and potentially risky; an algorithm or interface may be difficult to implement. The list goes on. If there is any significant uncertainty in the project, the project will benefit from shorter sprints. The short sprints mimic prototyping, and can be an effective way to hone in on the requirements or try out the technology before committing to a solution. If uncertainty is high, tend toward shorter sprints. If uncertainty is low, then look at the other factors.

2. The Amount of Process Required

The amount of process that needs to be accomplished in a sprint will affect sprint length. If implementing code and testing are the only tasks that need to be completed for a user story to be considered complete, shorter sprints are fine. Since most of Syncro Medical’s work is developing medical device software or mobile medical apps, quite a few tasks need to be accomplished in each of our sprints. We design, document design, review design, implement, unit test, review code and unit tests, write test cases, test, and fix bugs for each story. Therefore, our sprints need to be long enough to complete all of these steps. Otherwise, some of the process may not be completed. If process is light, then tending toward shorter sprints may be fine. If process is heavy, tend toward longer sprints.

3. Expected Project Duration

The expected project duration may impact the decisions for sprint lengths. A short project will benefit from frequent reviews. If a team uses 4-week sprints, a 3-month project will only benefit from three sprint reviews, while a 12-month project will have 13 sprint reviews. In my experience, a project as short as three months will benefit from more reviews and therefore provide more opportunities to inspect and adjust the subtleties of the project. So, if the project is short in duration, tend toward shorter sprints. If the project is long in duration, continue to look at the other factors.

4. Fine-tuning the Developer’s Environment

Sprints tend to add stress to the team. Some degree of stress is a good thing; it helps to keep the team focused and often causes the team to perform at a higher level than if there is no stress at all. On the other hand, if there’s too much stress, it’s more likely to diminish productivity. The impact of stress also depends on the personalities of each developer. Some personalities don’t handle stress well. Others rise to the occasion and seem to thrive on stress. (We do consider the client’s needs and the expected stress level of each project when selecting team members.) The key is to find a balance where the stress helps to focus and motivate without distracting. The development team needs to be optimistic – to own the sprint backlog and feel confident that they will produce a good increment in the allotted time.

5. Keep your Developers Close and your Stakeholders Closer

Stakeholder visibility and feedback are important reasons for sprints. The product needs to meet the stakeholders’ expectations. It’s one thing to imagine how the software will work; it’s another to see it in action. That’s why the iterative, Agile approach is so effective. Each sprint provides an opportunity to show progress to stakeholders. Additionally, each sprint gives stakeholders a chance to request revisions, reducing the need for costly changes later in the process. When the stakeholders are expected to provide input, tend toward shorter sprints. Otherwise, keep looking at other factors to help guide the decision.

It’s a “Goldilocks” thing

Too long? Too short? What’s the right sprint length? It needs to balance all of the items above and will depend on the project needs and goals. If there is uncertainty and/or the project is of a short duration, then 1- or 2-week sprints are best. While it may take a little longer to complete the project, the final product should be well-received and meet the product requirements. If the uncertainties are minimal, the team can stay focused, and the project is long, then 3- or 4-week sprints work well. If the stakeholders want more opportunities for feedback, then a 2-week sprint might work.

So Where Do We Go With This?

At Syncro Medical, we tend to start with 3-week sprints. For most of my medical device and mobile medical app clients, this seems to achieve a good balance of getting stakeholder feedback frequently enough to refine requirements and still implement according to process. Typically, requirements are sufficiently defined and the project is expected to take at least a year. The team is able to implement the sprint backlog and address all of the process in each sprint. Stakeholder visibility is sometimes enhanced by a weekly meeting to discuss progress, plans, and open issues.

But 3 weeks does not always make the best bowl of porridge. At times, we have exceptions to this 3-week preference. For instance, with one of my mobile medical app clients, we started developing a new concept and the requirements were only known at a high level at the time. We implemented the ideas in 2-week sprints, which allowed for changing and tweaking requirements from sprint to sprint. The opportunity for frequent feedback was instrumental in determining the final shape of the product. We really were working in a combined development/prototyping mode rather than in pure product development fashion because process was not addressed until the dust had settled on requirements.

Sometimes we have clients who specify their preferred sprint length. Clients trump Goldilocks here. In these situations, we use the client-specified sprint length.

In determining your sprint length, there may not be a perfect answer, but considering these factors will help an experienced scrum team dial in an optimal approach.