How Long Should an Agile Sprint Be?

Question

I'm currently PM on a project that is scheduled to run for about 14 months. The current sprint structure is 4 weeks of development; week 5 allows us to show progress to the client, deploy it for their testers, eliminate bugs and discuss the next sprint.

Given the length of the sprint is 4/5 weeks, it will generate 13/14 sprints. Is this a reasonable number of sprints, or should we look to have fewer sprints (say 8-10) for a project of this duration? Is there a rule of thumb on a reasonable number of sprints for a project with several man years of budget?

Answer 1

If you were new to Scrum and sprints, I would say you should start with some given length (3 weeks or 30 days) and check if it works for you and make changes if necessery. Instead, it looks like you are already familiar with sprints, so question is: what is your experience with sprint duration? Do you have any doubts which makes you ask the question?

I can see couple of influencing factors:

• Sprints come bundled with some additional time cost (meetings, plannings, demo, free day also?). Too short sprint means work/cost ratio will be low.
• Sprints should deliver. If you choose too short sprints, some of them will be dummy ones: with sprint goal not achieved, with almost nothing interesting to show on demo, sprint goal will be a stub itself and retrospectives will tend to be dull. In other words, sprint will fail to deliver.
• ...and deliver frequently. If you choose too long sprints, you will probably notice: overcrowded demo, too many goals per sprint and retrospectives where nobody remember what happened at the begining of the sprint. Client will be "flooded" with features once the sprint is over, so sprints are not frequent (agile) enough.
• There should be no delays between sprints. Do the demo, retrospective, backlog evaluations, (day off if there is such rule) planning meeting and start the next sprint. You should take a closer look at the 5th week as it takes 20% of your time. You can probably eliminate bugs in sprint time, make deployment easier and regarding PO's: they should have tasks for the next sprint prepared already, shouldn't they?

I can not give you the exact number of days sprint should take, as what I said above is tightly connected to the team quality, technology and architecture used, and product you are working on. It is probably not the best idea to change the sprint length too often because it affects your and team ability to predict velocity.

Answer 2

The shorter the sprint - the better. That's the rule of thumb. However there are many obstacles which do not allow us to deliver every, say, week. Some of these obstacles are:

• project sponsor/customer has certain bureaucracy
• resources (people) are slow in delivery
• some tasks take longer and can't be broken down to sub-tasks

These are the most important. Analyze yours and try to fight with them in order to make your sprints as short as possible. In general, your 4/5 weeks duration looks reasonable for average circumstances. But again, I would recommend to try to make it shorter.

Answer 3

In general the shorter the sprint, the better even when you are starting. The shorter the sprint, the sooner to inspect and adapt. Shorter sprints will also encourage better agile practices: reducing work-in-progress, reduced batch size and better throughput. Longer sprints can encourage old waterfall habits. In a recent webinar we delivered to 2,800 people we polled attendees for the most common sprint length and slightly over 50% responded with 2 weeks. This is the sprint length we generally recommend although there are more mature teams that have no sprint at all.

Answer 4

According to ScrumMethodology.com, a sprint is 30 days long. However, I can see advantages and disadvantages in having both longer or shorter sprints.

The longer the sprints become, the less agile you really are, especially if you follow the scrum methodology rules that don't let you interrupt or change the sprint in the middle.

The smaller the sprints, the more agile you become; however, it may be more difficult for the development team to get more work done since the product must be in a working version at the end of each sprint.

I feel like the complexity of the current sprints could very well dictate their length. If you're at the phase of the project where you're just resolving minor bugs, then maybe smaller sprints are easier. However, if you're making major changes to the system that require a lot of focus by the development team, then longer sprints may be more appropriate.

Finally, consider that if the sprints need to be longer than 30 days, you may need to check with the development team and ask them if they're designing the system with agile best practices in mind. Many techniques that are popular today, such as using a RESTful architecture, allow for independent deployments of modular components, which helps prevent bugs in other systems and create an environment where deployments can in fact be made more frequently.

Answer 5

From my experience I found it good to have 7-10 day sprints at the beginning and increasing it to 15-20 days later on as the team got to the norming/performing stages.

Answer 6

amelvin,

I worked on a three-team project where for a 15 month effort we ended up using two week sprints - this (for us) was the optimal length.

I say "ended up" because we quite deliberately, in the first few months, tinkered with a number of the basics, and sprint length was one of them. Longer sprints (IIRC, 4 weeks was longest we tried) was not effective. We felt feedback was taking too long to get (retrospectives), stories were less precise, and problems seemed to drag on rather than get closed down quickly. I don't believe this is a simple given - another project's teams might handle this better - but our experience was that shorter is better.

Answer 7

There is no rule here. The most common sprint length is 2 weeks. Vast majority of teams, I'd say more than 90% of those using time-boxing, would have anything between 1 and 4 weeks.

But then I don't believe there's a universal solution which suits everyone.

There are no rules regarding how many iterations you should have in the project or how the number of people in the team affects the sprint length. You can often hear "the shorter the better" but it's really about feedback loops. Ask yourself how short, or long, feedback loops you need. How often do you plan check up of your course? Since the end of each iteration is a natural occasion to perform such check it may be a good hint there.

Anyway, probably the best piece of advice if terms of deciding on sprint length you may get is: experiment.

Try with whatever feels good, you may choose one of industry standards if you have no better idea, and then look how things are going, adjust it and evaluate results. If you have 14 months for the project you also have enough time to find the right rhythm for you.

After all, much depends on people in the project team and this is something which can hardly be evaluated using simple methods. It's better to check what works and what doesn't than to make extensive analysis on the subject. See Nathan Furr's article on planning versus experimentation as a reference.

Answer 8

You can see good coverage on your specific question, but how is you 4/5 week length working for your team, client, system?

Have you tried other lengths? Did they deliver better results, was it easier to plan, deliver value, was the team happier?

How is your overall implementation of agile going? Is the 4/5 week time box helping you adopt the other part of the agile/scrum receipt for software development?

Have you stopped improving? Where did you start with your sprint length? Are you and your team actively managing the duration down like Ken Clyne talked about?

Based on those answers, I would say that you need to actively manage it yourself and skip the rules of thumb.

Answer 9

I think it depends on the project -- I managed project with 1 week sprints and 3 month sprints, so it really depends on what are the goals. I also believe that setting the realistic goals is most important.