4 Prerequisites for Reducing Sprint Duration

Agile manifesto has explicit stated preference for shorted sprints. Shorter sprints can ensure that:

  • “Parkinson’s Law” does not set in, that is work does not expand to fill the available time
  • “Understanding gap” between users and developers gets ironed out quickly
  • “Quick response to change” becomes possible

However, there are other factors which may make too short a sprint cycle counter productive.

Factors influencing sprint duration

There is a certain amount of overhead associated with each sprint. Every sprint requires some initial planning time plus validation, regression testing and integration time and effort at the end. This overhead is proportional to the total size of the software and the level of automation in place and does not depend on the number of stories delivered during the sprint. In short…

Do not attempt short sprint cycle without a mature engineering practice.

Otherwise, it would lead the team to burn midnight oil and lead to frustration.

If the product owner is always available for the team…

If all the stories are clearly spelled out…

If there is no confusion or disagreement on how the user stories are to be implemented…

…then short sprints are fine. Otherwise, stories cannot be delivered in a short sprint.

Do not attempt short sprint cycle without clear user stories.

But longer sprint may not be a solution because it will only introduce slack and waiting time. So, better idea would be to create a buffer of clearly defined user stories. Applying Kanban principles may help.

Third key point in deciding the sprint duration is the amount of time and effort required to implement a story. Several factors may influence that:

  • Architectural complexity
  • Existing technical debt
  • Skill level of the team

So …

Do not attempt short sprint cycle if, for whatever reason, the team cannot implement stories fast enough.

In short

If you need to have short sprint cycles, do the following:

  1. Improve your engineering practice to bring down the sprint overhead
  2. Ensure availability of clearly defined user stories
  3. Simplify your architecture and reduce technical debt
  4. Improve the skill level of the team

Related Articles

7 Responses to “4 Prerequisites for Reducing Sprint Duration”
  1. Mahadevan says:

    3 weeks is a balanced sprint duration…increase the technical and functional complexity gradually in each sprint..gives time for the team to settle and speed up

  2. Krisna Pawan says:

    Interesting reading. A recommended Sprint cycle should be for a minimum duration of 4 weeks to start with. The duration can be reduced as the team gains experience and understands engineering practices. However, it should not be less than 3 weeks, else the productivity starts declining.

  3. MADAN Kumar says:

    What is the recomended sprint duration? Is there a human factor involved, just wondering what is psychologically a confortable sprint duration without stressing out the team. I know a impending deadline is always a huge psychological burdon.

    • Udayan Banerjee says:

      Several people have told me that short sprints are stressful for the team. Has it been your experience also?

  4. Manmohan Pandey says:

    Outstanding article with key points

  5. Satish Puskoor says:

    Excellent article.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: