From the Scrum master's toolbox: sprint length

Sprint length

First a big note. The team sets the sprint length, not the scrum master, not the PO, and not the customer. The PO sets constraints in terms of expected deliveries (e.g. you can't have 4 week sprints if the delivery to production needs to be every 2 weeks). The scrum master does not set the sprint length. She coaches the team and can gives advice, but she should not decide the length of the sprint as it is the team who needs to make a shippable product at the end of each sprint.

Long sprints: 3 weeks or longer

In a 3-week long sprint you have a very long time between the planning and the delivery. This means that the shipped product will deviate more from the desired product, as there is less opportunity to adjust the direction. For example, at the sprint planning the commitment is for stories A, B ,C, D, E, F, but after one week, story E is less important and a new story X enters the picture. In an ideal case the PO would have wanted a product with stories A,B,C,D,F,X but she'll get A,B,C,D,E,F.

You should also expect the team to be able to commit to less. This is a simple consequence of compound uncertainty. Say we have story A and it has some technical uncertainty (e.g. unsure if an API has a good working cache). We also have a story B which also has some uncertainty but is is also impacted by story A. As story B is impacted by story A there is an additional uncertainty in story B which would not be there if story A was implemented.

Stretch goals

There are ways around those downsides. A typical way of dealing with compound uncertainty is the use of stretch goals. These are items from the backlog, which are in the sprint but are not part of the commitment. This is very risky in terms of expectations and needs a lot of coaching of the PO so it is clear that these stories are not part of the commitment. "The team is committed to deliver stories A,B,C,D,E. If all the stars are aligned and it doesn't rain you might get something of F or G."

Mid sprint checks

Another tool you can use to deal with long sprints is to introduce a mid sprint check. This is a small get together where you take a small step back and see if the current sprint is still on track. You can use a simple thumbs up/down to ask the team if they believe the commitment can be made. This would also be a point where you come to the conclusion that the sprint is not meeting its goals. In this case don't hesitate to abort the sprint. Aborting a sprint should be more common in a long sprint as the uncertainty is larger.  You can also do a light version of the mid sprint check during the dailies, just make sure that don’t start the discussion in the daily but take the discussion to a separate gathering.

Sprint stability indicator

Your sprint backlog will change. Supercritical stuff will pop up, stories will get blocked. With a long sprint this is far more likely and you should expect the amount of change to be more than just the linear extrapolation of a short sprint (a 3 week sprint will have more than twice the amount of change than a 1.5 week sprint). A good practice is to measure this change as a sprint stability indicator. It is simply the fraction of completed stories which were part of the planned stories (including stretch goals). 1.0 means all stories which were completed were planned, while 0.0 means none of the stories completed where planned.

Upsides  

The benefits of long sprint are especially visible when you are running a distributed team.  Phone conference meetings, no matter the technology used, are less effective than face-to-face meetings in two ways. Firstly: you are constrained by the tools you use to facilitate communication, and secondly you miss out on a lot of social interaction. The long sprints can help justify the expense of having co-located sprint activities, as meeting in person once every three weeks is cheaper and costs less travel time than meeting weekly or every 2 weeks

A second related benefit is PO availability. A perfect PO has full authority and autonomy to make big decisions related to the product. In practice these people are, especially in large organisations, high up in the hierarchy,  and quite busy. So in practice you most often deal with a proxy PO who has limited autonomy to make decisions. Having a long spring might make it possible to have the real stakeholders and the real PO in the room so that the feedback you get as a team is more relevant and the decision makes get better information regarding the project.

Make sure you take advantage of the longer sprint activities. If you have a 3-week sprint ist it fully justified to take a full day for it. Taking a full day for these activities make it easier to organise it outside of the normal working space, which helps team building, and it helps to create the right mindset for retrospectives.

Short sprints: 1 week

Short sprints have consequences as well. A sprint ends with a shippable product. Any time you spend on the release process you will have to do more often, and hence the total time spent on release activities is bigger. A second consequence is that sprint activities take relatively more time. In an ideal situation this just scales, so that in a three week sprint these activities take three times as long. In practice this is not the case; there is some overhead in any meeting.

Alternate activities

To deal with the overhead of sprint activities you can choose to alternate some activities. For example you can do retrospectives every two weeks and a detailed story breakdown session the other week.

Upsides

The downside mentioned above can also be an upside. The big question to keep in mind is "Is it worth solving?". Is the problem you are facing because of the short sprint length a problem that is important to solve? If this is the case, than encountering that problem often is a great thing. It gives much more learning opportunities, and a larger pressure to solve it and more opportunities to experiment.

Short sprints also work well if the project context is unstable, projects where there is a lot of disturbance and where priorities are changing often. With short sprint questions like "Can this be done I need it urgently!” can be answered by "Yes we can do it and we'll start working on it Wednesday."  Which is, in most cases, acceptable.