How Should You Determine Optimal Sprint Length in Developing Your App?

Melissa is a mother of 2, lives in Utah, and writes for a multitude of sites. She is currently the EIC of HarcourtHealth.com and writes about health, wellness, and business topics.

If you’re developing an app or a piece of software using agile methodology, you know you’ll need to develop critical features in a series of segments known as “sprints.” While there are some standards set by development communities, such as the fact that a development team has the final say in what can be done in a specified amount of time, you’ll ultimately have significant flexibility in how long your sprints actually last (as well as what’s included in them).

As Rose Marcantonio, Director of Quality and Process at Syncro Medical, writes, “The experts indicate that sprints ranging from 1- to 4-weeks are optimal, with a preference for shorter sprints. However, short sprints don’t work for every project.”

So what criteria should you use in deciding your sprint length?

Overall Project Duration

Most projects come with some kind of long-term deadline. If you’re developing an app for a client, they may want the app done before a specific tradeshow, or to accompany a product release. If your project is internal, you may try to complete the project as soon as possible. Most “average” apps take between 4 and 6 months of development, while some can be completed in weeks, and others may take years. Generally, you’ll want at least a few review periods to comprise your project, so if you’re aiming for a fast development (1-2 months), prepare for at least 3 sprints within that timeframe. Naturally, those sprints will be shorter.

Process

Think about what kind of process you’re using. For some lighter projects, like mobile games, your only tasks for a sprint may be implementing code and testing. But for heavier, more in-depth projects, like developing medical device software, you’ll need a more extended sequence of steps, such as designing, document designing, reviewing design, implementing, unit testing, code reviewing, and unit tests, followed by testing and fixing. For shorter processes, shorter sprints are manageable, but for longer processes, you’ll need some extra time.

Developer Manageability

You’ll also want to consider how your developers will be able to handle a given sprint. It’s good to put some pressure on your dev team to get an optimal performance, but you don’t want to push them so hard they become overly stressed and lose morale. Work to find a sprint length that’s challenging, yet reasonable, and in line with your developers’ abilities. As you become more experienced as a project manager, you’ll have an easier time understanding where this line is drawn. Until then, rely on feedback from your developers to understand their limits.

Stakeholders

The end goal is to make your stakeholders happy, and sometimes that means finding a compromise with sprint length. Many stakeholders are aggressive, and want to see results as fast as possible; in these cases, it may be better to opt for shorter sprint cycles. Others want to get as close to a finished product as possible with each sprint, affording you more time between cycles. Don’t let your stakeholders completely dictate how the project is shaped; after all, your developers’ opinions matter, too. But do keep their interests in mind as you set the stage for each new sprint.

Uncertainty

You’ll also want to factor in some extra time depending on how uncertain you are about the nature of the project. If there are considerable unknown variables, such as problems that might come up, ambiguities in the project description, or challenges that don’t have a clear solution, you’ll need to budget extra time for the sprint. The more certain you are, the more accurately you can estimate the length of the sprint with your development team. For this reason, the more details you have in advance of the project, the better.

Maintaining Flexibility

Though your sprints and project deadlines should be taken seriously, they also shouldn’t be set in stone. You’ll need to include some degree of flexibility in all your projects, for the sake of your developers, your product, and your own sanity. As Dan Radigan, Senior Agile Evangelist of Atlassian states, “The ability to change and adapt future plans based on current insights is a hallmark of agility.” Keep that core of agile development alive as you set the duration of your first sprints.