How do I convince my team, which is working on three week long sprints, to work on two week long sprints instead? The idea is to get quicker feedback from the Product Owner. The team doesn't get that.
As far as I understood your situation (you explained in the comments) the problem you are trying to solve is the missing feedback from the PO. It seems that you only get it end of the sprint.
If you want more feedback you do not necessarily have to shorten the sprint. You could
- Introduce a PO Acceptance as part of the Definition of Done so the PO checks the user story when it is considered implemented
- Create smaller user stories that can be implemented within a shorter amount of time
While my gut tells me that your team may benefit from shorter sprints, I would caution that you're being very prescriptive. That is, you've already decided that going to 2-week sprints will fix your problems and you're now trying to get people on board. It'll be better for the team in the long run if you help them develop good habits identifying and solving problems in the team themselves as a group.
For example, if the problem is that stories aren't meeting product owner needs, ask why. Maybe they say that they finish a story, then the product owner says it's wrong. Maybe that's because there isn't a proper understanding in sprint planning or maybe you need to touch base between the PO and devs more often. Ask the team for an idea of how to make it better and you can set up an experiment for a sprint or two to try it out. Experiments should be clear about what actions will be taken, what you hope to solve with it, and what to watch for as success and failure conditions.
Because you have longer sprints, maybe make sure to ask how it's going every few days or once a week. If I had to guess, I think somewhere in that process over the next few months, your sprints will become shorter, just because 3 weeks is a pretty long sprint for most groups, but who knows - Microsoft's VS team does 3-week sprints and seems to be doing fine with it.
Teams sometimes dislike the idea of shorter sprints as they worry that a larger percentage of their time will be spent in meetings. But the length of the sprint ceremonies should be proportional to the length of the sprint, so they will not be spending any more time than before.
There may also be technical concerns. Some teams worry that 2 weeks is not enough time to complete more technically complicated stories. This is when the importance of breaking stories down comes in.
Try and find out if these concerns (or others) are present in the team. If they are, work through them and build confidence in the team that shorter sprints can work. Remember though, at the end of the day it is the team's decision. So you need to win them over with reasoned argument.
The Scrum Master's role is to encourage the Development Team and the Product Owner to work together to resolve issues cooperatively, rather than trying to solve the problem through authoritarian decree. Don't turn a real problem (e.g. poor feedback loops) into a X/Y problem by assuming that the cause is your Sprint length. This is a logical fallacy, most likely a variant of post hoc ergo propter hoc.
The real root cause of your poor feedback loops is the lack of routine or continuous engagement by the Product Owner, which is a requirement of a functional Scrum implementation. Addressing that, and working around it effectively, should be the focus of your team's problem-solving efforts. Changes to the Sprint length is only one possible solution, and may not even be the best one. YMMV.
Your Problem Statement
PO is in a distributed location and ina different time zone...How do I convince my team who is working in three week long sprint to work on two week long sprint? The idea for me is to get quicker feedback from Product Owner. [sic]
Your Problems, Identified
You have articulated the following set of problems:
- Lack of day-to-day engagement from the Product Owner. This is a Scrum no-no.
- Lack of timely feedback on product increments, which is apparently only received during Sprint Review.
- A team that doesn't see a benefit to the team in having shorter iterations.
Your Possible Solutions
In order to address the problems that you have, you need to drop the idea of "convincing" the team to do something that they don't feel is in their best interests. This is not agile; it's a holdover from old-fashioned command-and-control project management. Instead, you should consider addressing the identified issues in a Sprint Retrospective and eliciting solutions from the entire team, including the Product Owner.
Pragmatic solutions may include:
Smaller Sprint Backlog tasks that follow the INVEST mnemonic. This offers the Product Owner more inspect-and-adapt points within each iteration.
Stories may need to be decomposed further, and Sprint Backlog tasks shortened to fit into a more measurable 0.5-2.0 day inspection cycle.
Ensuring that the Product Owner is available during defined core hours.
The use of Skype, telephone, email, or anything else that allows two-way communication between the Development Team and the Product Owner would allow the PO to answer questions and negotiate implementation details with the team. This is possible even when the PO is unable to sit with the team.
Provide opportunities for the Product Owner to provide feedback on increments early and often.
As one example, perhaps the PO could inspect tasks or stories as part of the Definition of Done within the Sprint, rather than only at the end during Sprint Reviews.
Identify the reasons that the Development Team doesn't feel shorter iterations are a benefit for them, and address those things together.
Some common examples may include:
- Stories that aren't small enough to fit into a shorter iteration.
- A Definition of Done that includes tasks that would make a shorter iteration impractical.
- Resource constraints that would make shorter iterations unsustainable.
- Higher framework overhead due to required Scrum ceremonies taking up a larger percentage of available time. (NB: There's a related post that discusses this overhead in detail. The takeaway is that shorter iterations provide tighter feedback loops, but at the cost of higher process overhead.)
The role of Scrum Master is to act as a framework referee and process coach, and to offer advice to the team based on his or her prior experience, not to prescribe implementations details beyond the framework-mandated ceremonies. Make sure you encourage the Development Team and the Product Owner to work together to resolve the issue, rather than trying to solve the problem yourself through authoritarian decree.
Playing with the sprint length is a good idea if you are facing issues. While getting early feedback is a good thing, you should also look at the concerns that the team foresees with the new sprint length.
Would they be able to slice the stories small enough to finish in 2 weeks? You also said there is not a lot of automation which would mean that the testing for now would take longer. Try to look for a solution on these angles and you might be able to convince the team.
In the past we had to switch to shorter sprints mainly because we were having bad estimations and deviations from the plan.
When we reduced the duration and thus the scope the estimations improved and deviations were smaller (I guess that as you see the delivery date closer you are more conservative when estimating).
Anyway I agree with others, if you plan to change the duration:
- Do it to solve issues.
- Get people on board first and plan the change latter.