How long should an Agile Sprint be?

Question

I'm currently the 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 the progress to the client, deploy it for their testers, eliminate bugs and discuss the next sprint.

Given the length of the sprint is 4 to 5 weeks, it will generate about 13 to 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

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 5

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 6

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 7

According to ScrumMethodology.com, a sprint is 30 days long. However, I can see advantages and disadvantages in having both longer or shorter sprints. In fact, the Scrum.org website's Scrum Guide describes a sprint as being no more than 30 days for the following reasons:

Sprints are limited to one calendar month. When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase. Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month. Sprints also limit risk to one calendar month of cost.

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 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

In one of my projects which last 60 weeks (similar to yours) my team has worked in 4-week sprint and it has been going well.

However, to answer your question: There is NO rule of thumb on reasonable number of sprints. I have been managing many projects, currently 5 projects at the same time. Some of them last for less than 10 sprints, some last 10-30 sprints, and some particularly long projects take > 50 sprints. And each project can have different sprint length (1, 2 and 3 week).

In Agile group where I participate, many teams choose 30-day period, while many teams choose 2 weeks and 3 week.

So how do I determine the sprint length? The decision is made after considering: Estimated length of project, nature of product, nature of your team.

1) Estimated length of project.

The estimation needs not to be precise 100% to give you a sense of how long the project will last. If it last more than 6 months, it makes sense to consider 3-week length or 30-day length.

2) Nature of product.

You need to ask yourself:

• Does this product need to adapt frequently to market/real users’ need to make value for stakeholders? If it does, you should shorten the sprint length and give more frequent workable version to get public’s feedback.
• Technically, is it possible to deliver product in short iteration? As you know, short iteration is encouraged, but you cannot do it 100% of the time due to technical difficulties. In some project we need to implement complex algorithm for example, before showing it to stakeholders.

3) Nature of your team

Does your team work most efficiently in 1-week sprints, or in 30-day sprints? If you have worked with the team on several 2-week sprint and you feel that they work well, why not consider it?

You may have the temptation to try 1-week sprint, but keep in mind that the actual work of coding is reduced, due to the (almost) same amount of effort spent on Agile (meetings, communication, etc..).

In my current projects, for maintenance projects we often choose 1-week sprint and for others, we are working efficiently in 3-week sprints, and 4-week sprints, for to share personal experience.

Answer 10

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.

Answer 11

Shorter Sprints generally Trump longer Sprints.

From a much longer blog post Shorter Trumps Longer

Pros

• Since the team has more but shorter retrospectives they have more opportunities to try smaller changes. This also provides more opportunities to learn.
• More frequent Sprint Reviews give the Product Owner more feedback and more frequent opportunities to change. This should largely eliminate the need for the Product Owner to ever ask for a change (i.e. new Story) in the current Sprint.
• Impediments and Slowdowns are highlighted more quickly, since the team is expected to get the feature(s) to done by the end of every Sprint. This forces the team to come to terms with things that are slowing them down.
• Shorter cycles make planning easier, which increases focus and reduces the amount of “dark work”. Forces teams to do a better of job of slicing Stories or Features into smaller chunks. This increases visibility and gives the Product Owner better control over prioritization and deprioritization.

Cons

• It’s harder to get to a finished product at the end of one or two week cycle. Caveat this is true at first however most teams are able to get the hang of it after three to four Sprints.
• Working in one week Sprints can be more stressful at first.
• Overhead – people say that the Sprint Meetings are too much overhead for a one week Sprint. However sprint meetings scale linearly with the length of a Sprint. So a one week Sprint will have 2hrs of Sprint Planning, a two week Sprint have 4hrs and so on.

Today most teams I encounter pick two weeks Sprints. Some go as short as a week.

Answer 12

I think a good sprint should be around 4 weeks. so basically equal to an iteration. An iteration does not necessarily have to be a production grade release, but should at least be an internal release for testing. Each sprint should aim at completing several user stories ready for testing

Answer 13

The developers on the team should decide what works best for them. It may be that short sprints work best at the start, then longer sprints in the middle, then shorter sprints at the end. Or vice versa. Or all the same size, at 4 weeks. Or maybe 4 weeks turns out to be too long for the empirical approach that is Scrum, so the developer team may decide to cut it back to 3 weeks.

Fortunately for the PM, the length of the sprint is not the PM's concern. Assuming the PM is the product owner, and not one of the developer team members.

Answer 14

Amelvin,

A few thoughts about what you shared with us. I understand you must adapt the framework to the specific circumstances of your company, but here are a few things I would personally advise against.

Why the 5th week pause? One of the goals of scrum is to maintain a sustainable pace. If you need a break every 4 weeks that suggests to me that you might be overworking the team the other 4. Will you be able to sustain that for 14 months?

Deployment tasks should be included in the sprint. or even better, As much as possible aim for deployment automation. they should not be the excuse for the off week either.

The need for bug fixes raises the question of quality control. How are you ensuring quality in your sprints? How has your definition of done evolved? Having a bug fix week leads the development team to cut corners and reduce the quality. It feeds the line of thought that problems "can be dealt with it during the bug fix week". And before you know it, items you thought were done, keep coming back for fix after fix. A healthy DoD is crucial for transparency and transparency is key for project success. My advise is to be strict with your definition of done and push the team to make it grow on every retrospective. Non-Functional requirements are great candidates for Definition of Done check points.

The last activity you seem to bundle into your off week is estimating and PB grooming. You don't need to have the entire backlog estimated and prioritized but you should have 2 to 3 sprints worth of stories ready to go at all time. To do this, the product owner should be regularly checking the priorities and the team needs to set time aside during the sprint for a poker planning session or whatever estimation approach you use.

Have a read through the scrum guide from scrum.org, and I would suggest getting the whole team going through some formal Scrum training from either .org or from the Alliance. Most decisions need to be made by the team. E.G. Sprint duration should be determined by the Scrum team. It's always better when everyone understands the basic guidance and the reasoning behind it.

Good luck for your project

Answer 15

I'm more on the development side, and I just wanted to chime in here.

One common mistake I see PMs make, is to try to lock blocks of work into a regular schedule, rather than scheduling the block of work.

For instance, consider a situation with 6 planed blocks:

• Feature A (1w 3d)
• Improvement B (4d)
• Feature C (1w 1d)
• Approved BugFixes (3d)
• Refactor 5 (2w 4d)
• Error Handling Improvements (2d)

Attempting to chunk these into 2 week sprints will force ordering them in a way which will create more work for your dev team, and break up some blocks into multiple sprints. This is exactly what agile is supposed to avoid.

Instead, consider planning the blocks that need doing, how much time each will take, and the logical order they should be delivered. Then make each block its own sprint, and schedule them. Let there be a 2-day sprint for Error handling. Let there be a 3 week sprint for the refactor. Project Management and scheduling should manage the project, not drive it.

Answer 16

This is a tradeoff. If the sprint duration is extremely small, there are higher overheads such as # of retrospectives, demos etc. So the transaction costs are high. If the sprint duration is too long, then the completed features reaching in the hands of customers takes longer resulting in delayed revenue. i.e. Higher Holding Costs. Your optimum Sprint duration is when your transaction and Holding costs meet.