Fixed Sprint Lengths Considered Harmful

Scrum advocates the use of fixed length sprints. The  length of the sprint can be adapted to balance between the need to release rapidly and allowing enough time to complete a useful amount of work in each sprint. Once an appropriate length is found, it generally stays the same.

While fixed length sprints are an improvement over waterfall style development in many respects, it imposes an artificial deadline for teams and this can cause inefficiencies and technical debt.

Sprints may have fixed lengths but user stories, on the other hand, are not homogeneous at all. Stories differ wildly in complexity and the time required to complete them. Teams will estimate their size and then commit to completing a certain number in a sprint. Seems reasonable enough but….

A scrum team will ALWAYS either over-estimate or under-estimate the amount of work that can be completed in a sprint.

This leads to one of four possible scenarios occurring.

Scenario 1: Team under-commits a lot

Team under commits a lot

If a team under-commits a lot, it is usually not serious as a new story can easily by in-scoped, which will lead to one of the other 3 scenarios being triggered.

Some teams may in fact work more slowly in order to prevent a new user story being in-scoped, either consciously or unconsciously. This risk, however, probably only applies to highly unmotivated teams.

Scenario 2: Team under-commits a little

Scenario 2

If a team under-commits only a little bit, however, it is more serious. Work is like a gas and has the tendency to grow to fill the available space.

Teams may find that if they are slightly ahead of schedule that they don’t feel want to feel the pressure of the end-of-sprint deadline and that they slow down the pace.

Scenario 3: Team over-commits a lot

Scenario 3

If the amount of over-commitment is big, similarly to scenario 1, it is also not serious because the team can compensate by out-scoping a user story. This then leads to one of the other scenarios being triggered. Alternatively the team may decide simply to fail the sprint.

Scenario 4: Team over-commits a little

Scenario 4

A small over-commitment is dangerous as it plays into well meaning team members’ positive mental attitude of “we can do this”. This attitude in scrum is harmful as it encourages people to a) work harder and or longer and b) to take short cuts.

Working harder or longer (than normal) results in a non-sustainable work environment. This is like your team members taking out a loan that they have to pay back later (with interest). It doesn’t work over the long term and will often result in tired employees making mistakes and also to take short cuts (see below).

Short cuts are when quality is compromised in some way to reach a deadline. Short cuts are something like the product taking out a loan that must be paid back later (again with interest). This results in a build up of technical debt, poorly designed areas of code, untested or under-tested features, bugs and so on.

Non-optimal ordering of stories

In addition to the inefficiencies and technical debt risks described above, there is another issue with fixed length sprints. Both the product backlog and the sprint backlog should be ordered sequentially in order of importance. It is the product owner’s responsibility to ensure that the user stories are in the optimum order for the business needs.

Unfortunately, the artificial deadline of a fixed length sprint encourages stories to be done in a non-optimal order.

Stories undertaken at the beginning of a sprint are less risky as there is time and resources in abundance to correct or work around any issues that may arise.
Conversely tasks undertaken late in the sprint (towards the deadline) are risky. There will be much less time to work around any unforeseen circumstances that may arise and it may cause the story to be out-scoped and thus released much later than planned. It may also cause the sprint to fail.
From the product owner’s perspective she cannot rely on the team delivering late sprint user stories as much as early sprint user stories.

Larger, complex stories are higher risk than small ones, and some stories may simply carry inherent risks (such as reliance on external parties).

Project managers and product owners don’t like surprises, so frequently teams will massage the stories into the sprint in a different order than the actual priority. By placing high risk stories earlier in the sprint and leaving low risk stories for the end the sprint is more likely to succeed and it is less likely for stories to be out-scoped.

This means, however, that teams are doing work in a non-optimal order. You may be working on less important things before more important things simply because of the artificial deadline imposed by the sprint.

What’s the solution?

How can you achieve a 100% perfect fit of stories into a sprint? Despite everything said so far, it is in fact possible quite easily. By abandoning the fixed sprint length you can make a sprint fit instead around the stories inside it. You’ll never need to fail a sprint or in-scope or out-scope anything ever again. It makes a commitment unnecessary thus eliminating the need to make difficult estimates, saving time and energy.

Most importantly, however, this approach eliminates the problems associated with over and under commitment. This means the team doesn’t need to rush to finish thus taking short-cuts. Design will be done properly, code properly reviewed and stories properly tested.

What about measuring velocity?

Velocity in scrum is the measurement of stories achieved over time. Usually this is measured by tracking the stories completed per sprint. It makes little difference if velocity is measured in stories per week or month than in stories per sprint. In fact measuring stories per week is more flexible as it doesn’t depend on the sprint length (which, while “fixed” may need to be changed at some point during a projects lifespan).

Will my team be motivated if they don’t have a deadline?

It is possible that certain individuals respond well to deadlines and will perform better with this pressure. You have to consider the costs that are incurred, however, of rushing to finish along side this possible benefit. Plus, there are surely better way to motivate people than deadlines. If you’re trying to squeeze every last drop of productivity from the team, you should remember that you’re also saving time by eliminating quite a bit of processes.

I need fixed release dates, so I need fixed length sprints!

Ask yourself why that is really important. Perhaps your release process is too heavy weight. Remember that if something is painful in your processes, you should do it more often and automate it (think continuous delivery).

In summary

You may well need fixed sprint lengths for your particular team, but you should consider the reasons why and the costs associated with it. If you do it because you’ve always done it, maybe it’s time to reconsider. Ideas such as Continuous Delivery, which advocate easy and light weight software releases don’t need fixed sprint lengths. You may, overall, be better off planning a release when the next batch of user stories is correctly specified, implemented and tested, and simply removing the artificial deadlines from your process.

Instead of spending time and energy trying to estimate how big stories really are and how many you can do in the next fixed length sprint and constantly tracking progress, why not just focus your time on creating high quality software that works correctly.

Tags: , ,

Comments are closed.