Are We Required to Have 2-Week Sprints?

You can have shorter or longer sprints depending on the team's needs and product demands.

As the team progresses and becomes more efficient at delivering business value faster, it may reduce a sprint from 2-weeks to 1-week. The first step is to ensure the team will be able to keep a velocity of deploying once per week. Can the team deploy weekly? The team should agree a reduced sprint time is achievable and that it will best suit the team, stakeholders, and customer's needs.

Operational or support teams typically make minor changes to keep the product up and running for customers. These changes are small and developed quickly. Robust automated testing ensures changes are thoroughly tested to ensure system performance is not degraded or outages occur. Typically, a 1-week sprint is a good fit for these types of teams.

Teams that are developing new capabilities and products work on more extensive changes. These changes are often complex and highly integrated with other systems in the organization. Development-type teams typically prefer a 2-week sprint cycle. Teams should choose this length if they can consistently deploy every 2-weeks.

Teams developing in enterprise-wide systems or large-scale legacy applications may need to segregate work into different teams. Small minor changes are deployed in 1-week sprints by a support team. More extensive complex changes are handled by another team that deploys every 2-weeks.

Some teams have long development cycles and cannot fully develop, test and deploy in a 2-week sprint. Their development cycle time could easily extend to 3 or 4  weeks. In this case, teams would pick a sprint cycle of 3-weeks or 4-weeks to best align with their development cycle to deploy to the customer consistently. 

Consider any sprint cycle change carefully. Going from a 4-week sprint to a 2-week sprint overnight can be very difficult without ensuring the underlying development process is streamlined.

Consistently streamline the development process first. This will result in the team being able to reduce sprint cycles. Streamlining can be achieved with automated testing, improve development tools, improved deployment tools, and resource development.