What are the benefits of having fixed length sprints for agile?

Question

Lately, I have been the solo developer on a software development project and I break down my project into functionality that I believe I should be able to implement in 1 or 2 weeks depending on the feature.

Sometimes I get my estimate wrong. Examples:

a) I estimate a week and the feature takes 1/2 a week to finish b) I estimate 2 weeks but the feature set takes 3 weeks to finish.

Why not just set your goals for the iteration and finish them in the time it takes rather than have a fixed iteration that you miss by finishing too soon or too late? What are the benefits of a fixed iteration development time?

Answer 1

The idea behind the fixed length sprint is to provide a understanding between development and the customer (or PO) when something new (and working) will be available, and to define the length of the feedback loop, which is equals to the length of the sprint.

In other words, the customer will know that she will get something in 2 weeks, which works, and the development team will know that they'll receive feedback on their work and know more about the upcoming work in two weeks. That's predictability.

Let's get back to the feedback part. The length of the sprint helps you find the right balance in work. You cannot really take more work than you can do in two weeks, so an agreed length can relieve the development team of an unnecessary pressure.

If your feature set takes three weeks, then you have to find way to break it down into smaller tasks or user stories. The whole idea behind Scrum is to shorten the feedback time. If you spend three weeks on a user story you'll get feedback minimum in three weeks. If you manage to break it down to three, one-week long user stories, the first feedback will arrive in one week, which is extremely good.

Why not just set your goals for the iteration and finish them in the time it takes rather than have a fixed iteration that you miss by finishing too soon or too late?

It really depends on the way of working you are following. Let's say you are working alone, and the next team or group which will get your code doesn't care when it arrives, then you can switch to a continuous model like Lean (or Kanban). If they want to receive your work in every two weeks, then you don't have other choice to deliver in a two week long cycle (unless you can convince them to switch to a continuous model).

Before picking a model check the whole system (from customer back to the customer) and pick a model which provides the following benefits: quality, speed, reliability and predictability.

The last thing: stick to the model. If you are doing (or have to follow) scrum than dynamically changing the length of sprint is out of question, because without a fixed sized sprint it simply won't work, because you'll lose the speed, reliability and predictability.

Answer 2

When I took a scrum class, the instructor showed a graph similar to this one.

This is a chart of the amount of effort exerted by developers in a classic waterfall project vs the amount of effort exerted by the developers on a scrum/sprint-based project. The idea is that by creating a lot of little deadlines, it increases the effort exerted on the project for each sprint deadline rather than waiting until the very end of the project when people start realizing THE deadline is coming and they start working crazy hours for weeks on end.

Your estimates are always going to be over or under by some amount. Scheduling is something that people can get better at over time. Like anything else, some people will always be better at it than others. But do your best to come up with good estimates.

One reason you don't want to go smaller than 2 weeks is that the overhead of the process (retrospectives, demos, signoffs, etc. if you are doing those things) starts to intrude. In an extreme case, you could have 52 sprints per years vs 26.

You want to try to avoid going longer than 2 weeks because when you start to schedule larger things, the amount of scheduling error increases. If you're dealing with some scheduling error already, that will only get worse.

Answer 3

Completely agree with Zsolt on this. Here's a good quote from Henrik Kniberg's Scrum and XP from the Trenches [free edition] which re-iterates the importance of predictability in sprint length:

once you have decided what length you like best, stick to it for an extended period of time. After a few months of experimentation we found that 3 weeks was good. So we do 3 week sprints, period. Sometimes it will feel slightly too long, sometimes slightly too short. But by keeping the same length this becomes like a corporate heartbeat which everyone comfortably settles into. There is no argument about release dates and such because everyone knows that every 3 weeks there is a release, period.

The book also has great advice on how to assess how many story points you are likely to be capable of completing within your sprint. This will help you avoid the situation where you promise something that can't be delivered in your sprint. By understanding your velocity (which will take time because you need to look at past data) you'll find your sprint planning becomes more accurate.

Answer 4

You don't need either if you are developing solo. Fixed length sprints are to ensure rapid & continuous feedback between product owners and developers, as well as continuous communication between developers in the form of sprint retrospectives. It also helps to ensure that user stories (requirements, product backlog items, whatever) are broken into small enough pieces. Most places I've witnessed that did not stick hard and fast to their sprint lengths slowly increased them over time, until they were basically back to semi-agile waterfall.

See scrum.org for more.