Monday 27 October 2014

Why fixed length sprints are important in Scrum

I have worked at several companies and on different projects doing Scrum. Some teams have been more disciplined than others in following the Scrum methodology.

In a few of these Scrum teams we have not adhered to the rule of a fixed sprint length, and the experience with that has always been negative. In this blog post I list reasons why variable or flexible sprint length is a bad idea.

Oh, and in case you wondered; fixed sprint length IS a well-documented best practice of Scrum [1], [2], [3], [4], [7], [8], [9].
Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened [1].
Sprints best have consistent durations.... A new Sprint starts immediately after the conclusion of the previous Sprint [1].

What typically happens in beginner Scrum teams or in teams where the Scrum master is busy doing other things than being the Scrum master is that they typically get into a situation where some stakeholder for example CTO, department manager or even the PO thinks it is a good idea to alter the length of the current sprint because that way you are able to finish a complete epic/module/product and have that released in one go.

The big problem with this is you easily fall into a slippery slope. Since you have extended the sprint a few days why can't we just extend it another day, and another day.

Another typical reason for not having a fixed sprint length is that resource availability will vary. So if there are vacations, bank days or you know some team members will be away you change the length of the sprint so that man-hours for each sprint stays about the same and you keep velocity the same.
For example; your team may decide that a sprint is always 15 work days. In practice you will then end up with different sprint lengths because resources availability will vary from sprint to sprint. Most people don't schedule and plan their entire vacation in detail many months ahead. That means that you will never know the exact availability of your team resources in the future. Also,you can predict how long a person will be gone if he breaks his leg in a car accident, but you can never know if or when a person will be in an accident in the first place. My point is that you can never know in advance how many calender days will match a fixed set of work days if you have decided a sprint should be a specific number of work days. Instead you should aim for a fixed length in calendar weeks, not work days. Calendar weeks are predictable, work days are not.  

Here is the full list of why you should stick to a fixed length sprint:

1. Improve coordination with the rest of the organization

It will be easier for everyone to know what kind of Sprint phase the team is in (e.g. planning, development, testing, reviewing). This predictability allows for better coordination and planning throughout the organization. The entire organization can sort of self-organize around this rhythm.

It also helps you to steer expectations. With a fixed length sprint everyone (PO, management, customers, users, and other stakeholders) will know when they can expect new upgrades (incremental improvements). They will know that a new upgrade typically comes every 3 weeks (or whatever your sprint length is).

2. Save time planning

With a fixed sprint length you can schedule and make plans more easily. A sprint is always the same length, that's it. Now you can schedule Scrum events for the next year ahead and you can do it in one go. You will have less overhead in planning because you don't have to negotiate what should be the sprint length each time, you don't have to make complicated man-days calculations and you don't have to change all the following sprints because you change the length of the current sprint.

Since you can schedule meetings in advance, people can plan their appointments around the Sprint events, rather than sprints being tweaked to fit the calendar of key team members or stakeholders.

3. Better quality

In general a fixed-length sprint will remove variability and this will lead to more predictability, stability, better flow, better and more sustainable work environment, less chaos. This of course leads to higher quality.

If you allow sprints to be shortened, say for example because the top management really want to have the next release earlier you not only loose rhythm but you will either have to work overtime, reduce quality, add more resources, or scope down the current sprint. If you scope down you waste resources and throw away planning/analysis that is already done and other work that has been started. If you decide not to scope down you are typically left with one option on such a short notice. You end up reducing quality for example by pressuring the testing to complete faster or by not letting developers do refactoring and other chores. If you decide to work overtime you still jeopardize quality since tired or pressured team members make more mistakes.

4. More effective work with better flow

With fixed length sprints it is much easier to get into a flow of doing all the Scrum related events such as backlog grooming, retrospectives, sprint reviews. With a predictable schedule you don't have to think about these events. When is the next meeting, will there even be one?

Without this fixed start and stop you may be tempted to move the start and stop date. You might even delay starting the next sprint long after the previous one ended. Beginner Scrum teams in this situation might not schedule the sprints for the months ahead but instead just start a new sprint when it makes sense. Before you know it you skip a retrospective and have to do sprint planning in the middle of a sprint. All this leads to more unpredictability, questions, chaos and less flow which eventually results in lower performance of the team.

5. Improve estimates

If the sprint length varies from sprint to sprint, then the amount of work accomplished in each sprint tells you next to nothing about what to expect in future sprints. Comparing how well you did on estimation in different sprints will be more difficult if you change multiple parameters of the process.

6. Enable continuous improvement 

Sprints can more easily be compared. In Scrum we try to fix as many parameters as possible; Time, Quality, Resources are fixed but we change the scope or work from sprint to sprint. By reducing the complexity down to just one adjustable parameter (scope / backlog) it will be easier to have discussions around opportunities for improving the process. The more variables you change the more complex the dynamics of the process will be and it will be much more difficult to compare sprints to improve the process. If you change multiple parameters around each sprint, how are you going to know for sure what actually contributed to things going better or worse?

7. Improve ability to predict when future features will be released

The organization or customer will know how long it will take to get new releases out the door if suddenly a new feature absolutely has to be introduced as soon as possible. E.g. If the team is in the middle of a sprint and the sprint length is 3 weeks it will take about 5 weeks to see the newly requested feature in production. If the sprint length is variable it would be far less obvious when you could expect the new feature.

For products planned several sprints down the road it would be even more unpredictable without a fixed length iteration.

Velocity (the rate at which a team delivers stories from the product backlog) is useful in forecasting when capabilities can be deployed and available to end users. Without fixed-length sprints, any measure of “work accomplished” is useless in forecasting. Alternatively you will have to make adjustments in the calculations of velocity based on the sprint length. These sorts of calculations become a waste of time as they are hard to get exact and just add extra work to the Scrum master. You can never hope to be 100% precise on task estimates so Velocity will never be exact science anyway. By having fixed length sprints you reduce one source or error in calculating velocity. Keep it simple, stay lean and pragmatic. Aim for predictability and simplicity and forecasting will be easier and less time consuming.

Sure there will always be holidays, sick days, etc. If a sprint has less resources you simply commit to less [5]. You calculate how many man hours is available and plan the scope accordingly. You may now say that this will affect velocity and number of storypoints delivered for these sprints will be lower. Yes and that is fine because you know the reason why. In the Velocity-over-time-graph you can just make a small note about vacation etc. when velocity had a dip. If you know most of the sprint is going to be all messed up because too many people are away you can also decide for the team to do something completely different. You could let developers take the sprint off doing courses, prototypes etc.

8. Improve team motivation

Fixed length sprint helps the team to deliver continuously and provides a sense of accomplishment at the end of every sprint. The team also commit to a chunk of work at the start of the sprint. The team gets motivated to deliver as they themselves committed to doing the work.

With fixed length sprints you have predictability and the team feels more at ease. People like to have routines and familiarity [5]. Fixed length sprints contribute to discipline, habits and traditions that creates team identity. "This is our team and this is how we do it." This again strengthens cohesion and team spirit, which is important for highly effective teams.

If Scrum events falls on random days of the week every sprint then it is hard to build good habits.

9. Accountability

Fixed length sprints with reviews at the end of the sprint encourages the team to deliver on the sprint review. Without a fixed sprint calendar the chance of skipping reviews gets much bigger. Without this regular review delivery the team may procrastinate, get caught up in coding what is fun rather than sticking to the plan or get distracted by other things. Developers don't want to look bad so they will deliver when it is demo time.

10. Better planning of backlog and roadmap

PO can better prioritize and split user stories now that meaningful data on velocity can be accumulated from sprint to sprint. PO can use this velocity as a guide to plan upcoming sprints.

11. Essential for multi team synchronization and alignment

When you scale to multiple dev teams doing Scrum (co-located or not) contributing to the same solution or product, it is obvious that synchronizing the teams will be more effective [6].

If the different teams operate with different Sprint lengths it goes without saying that the teams will not be in sync.

Conclusion

Scrum is all about delivering software in regular intervals to enable fast feedback and to get a effective cadence for the team.
Variable Sprint lengths may seem like a good idea, especially in the short term, but in the long run it will be devastating to the progress of a team.

If you liked this blog post, you may also want to read Scrum Best Practices: Choosing the Right Sprint Length.

References

[1] http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-US.pdf
[2] http://www.infoq.com/minibooks/scrum-xp-from-the-trenches