Is it possible to have a project with varying Sprint cycle? Example: in a product implementation project initial few sprints could be a month long because of multiple dependencies and lack of clarity but as we move forward the cycle becomes say 2 weeks long.

What all changes in the system (Like Target Process) a PM/Scrum Master has to do?

3 Answers 3


There are a few reasons for using a consistent size of sprint:

  • The team gets in to a rythm with a fixed sprint duration. They know when the Scrum ceremonies will take place and can easily allow for them when planning holidays, working from home and other absences.
  • With a fixed sprint size it is easier to engage busy stakeholders. For example, you can book them in to a sprint review many weeks or even months in advance.
  • The team will also get used to the appropriate length of planning and backlog refinement meetings. If the sprint duration is changing then they will need to make allowances for more/less planning in the sprint.

I would suggest that changing the sprint length is fine as long as you do it just once and anticipate a slight period of re-adjustment from the team.

A better solution might be to stick with a 2 week sprint throughout and try and resolve the dependency and clarity issues. Remember that one of the reasons we have shorter sprints is that the regular sprint reviews can help to draw out requirements and increase clarity.

  • Thank you. Should Sprint planning and break durations should also be considered as part of a sprint?
    – Ayusman
    Aug 6, 2015 at 16:28
  • 2
    Definitely. For example, the Scrum guide suggests a time box of sprint planning of 8 hours for a 1 month sprint. You would expect that to be reduced to 4 hours for a 2 week sprint. Aug 6, 2015 at 16:46
  • Another reason is that the team can better estimate how much they can take on every sprint based on past experience.
    – dramzy
    Aug 6, 2015 at 17:28

Generally you want to establish a cadence and keep the sprint duration the same but, there a lots of good reasons to change sprint duration after the project has started. Some common reasons are:

-Sprints that are too long become a planning nightmare -Sprints that are too long don't deliver features in a timely manner for customer feedback -Sprints that are too short don't align with story work complexity -Sprints that are too short don't allow enough room for improving product quality and sustainability (tech-debt, refactoring, etc).

Changing sprint duration may seem scary at first but if you consider all the stakeholders in the equation you will identify what processes and people are impacted with a change. Common impacts include activities around release planning, documentation, and customer-feature communication as well as your planning/review/retro.

Generally moving to a shorter release will tighten the feedback loop on your scrum team and force continuous planning behaviors that often are neglected when sprints become too long because teams/pm's believe adding more time to a sprint duration will address the uncertainty factor in delivering within a sprint.


Another option you might benefit from is the concept of a 4-week Sprint 0 that precedes the normal 2 - 3 week sprints. Sprint 0 is a great time for the project team to make basic architectural decisions that will impact the rest of the project and help ensure that future sprints are productive. The team basically puts the skeleton of the project in place. It's a great time also to clarify any fuzzy areas in the requirements/user stories. More great info at: https://www.scrumalliance.org/community/articles/2013/september/what-is-sprint-zero

Also, remember that the backlog should include technical stories, not just functional stories. This is something that took awhile for a few of my early teams to figure out. Once you get a hold of the Product Backlog, review it with the technical team and Product Owner and discuss technical options and stories that are needed to accommodate investigations and decision-making. Doing this makes the work visible and the team can plan for it within a sprint.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.