Sprint length changes for Sprint goal
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 ?
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.
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.
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.