Skip to main content

Sprint length changes for Sprint goal

Last post 11:13 am October 6, 2021 by Niall Fallon
3 replies
07:56 pm October 5, 2021

We normally follow 2 weeks sprint. This time PO said we have simple goal so we should go with 1 week sprint. The team also agree after sizing the items and commits that sprint goal can be achieved in a week. I told PO that we keep the sprint length constant and as soon as the required items are 'Done' it can be released anyime during sprint. But he told we cant push the team to achieve the sprint goal within 1 week if we have 2 weeks sprint. The team will take it to end of 2 weeks even though the sprint goal is simple. 

So if we go with 2 weeks sprint and team achieves the goal in 1 week of time, We take another small goal for 2nd week or we work on items that are not contributing to any goal ? 

09:03 pm October 5, 2021

But he told we cant push the team to achieve the sprint goal within 1 week if we have 2 weeks sprint.

Why would he, or anyone, try to push the team?

Scrum is based on respect and on pull.

10:27 pm October 5, 2021

There's quite a bit to unpack here.

One aspect is the changing Sprint duration. Although it was stated more explicitly in some older versions of the Scrum Guide as recently as the 2017 edition ("Sprints have consistent durations throughout a development effort."), it's become more implicit in the 2020 revision ("They are fixed length events of one month or less to create consistency."). It may be good to think about why Sprints tend to be of relatively stable length. Predictability and consistency help the team to learn from past performance. If the team continues to look at work in the same size chunks, it's one less variable to think about when determining how much work to plan and the team can focus on other things that do change, like the Definition of Done or their understanding of the product and environment. There may be good reasons to adjust the Sprint cadence, but it's not something that's done lightly and without thinking through the impact.

Ian does bring up a good point about pushing. Although pushing is usually discussed in the context of pushing work, it also applies to pushing processes or procedures onto the team, including decisions like the Sprint cadence. The Scrum Team is self-managing, and no individual should dictate the specifics about how the team works. The Sprint duration is one aspect of the team's way of working. The team needs to consider how the Sprint cadence impacts their ability to work with stakeholders and reach a decision among themselves.

The Product Owner assessing that the goal is simple and can be done in one week goes against a key principle of estimation. The best estimators are those who are doing the work. Unless the Product Owner is also a Developer, I don't believe that they are in a position to determine how long it will take to achieve the work. The question before the team should be if the goal and the work necessary to achieve the goal can be accomplished in one Sprint, where the Sprint is the team's standard two-week duration. If the team has additional capacity, they can choose how to do that. Perhaps they can add additional Product Backlog Items to their Sprint Backlog at Sprint Planning. Perhaps they can leave themselves with some slack and work on improving their cross-functional skills, self-improvement and learning activities, or have a buffer in case the unexpected happens.

It sounds like the Product Owner may be concerned with Parkinson's Law, which states that work will expand to fill the available time. In response to this, I'd point out the Scrum Values of Commitment, Focus, and Respect. The team is committed to achieving its goals, and I'd even consider achieving its goals effectively to deliver value. They focus on the Sprint Goal and achieving the goal is the primary focus of the Sprint. The team also respects their stakeholders' time and money and also earns respect by being effective at delivering solutions in a timely manner. Even more fundamentally, customer satisfaction through "early and continuous delivery of valuable software" is the first principle of Agile Software Development. A team that is embracing the values and principles of agility will hold themselves accountable to not fall into the trap of Parkinson's Law. In the context of Scrum, the Scrum Master should be supporting the team to follow these values and principles.

My recommendation would be to plan a two-week Sprint as normal. If Sprint Planning reveals that the team has additional capacity, the Developers can choose how to fill it. There's no need to establish a formal goal, and it would be up to the team to make informed decisions about what to take based on the state of the Product Backlog and their determination of what would be an effective use of their time. Not all work taken on in a Sprint Backlog needs to be explicitly tied to a Sprint Goal.

11:13 am October 6, 2021

Use short sprints if the product is unknown. This helps get feedback quicker and replan quicker based on the feedback.

I prefer the keep the sprint length constant, 2 weeks is a good middle ground.

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.