8

We were trying to figure out the optimal sprint length for our project. After working on a 3-weeks basis we thought that cutting the sprint to 2-weeks would provide better velocity.

The advantages were clear - shorter feedback loop, small stories (with user value) and so on. On the other hand, there are a lot of disadvantages such as ceremonies (planning, retrospective) and so on in which we don't produce and now happen more often.

I was wondering how, for a new team, can we decide on optimal sprint length?

Avi
  • 516
  • 5
  • 21

7 Answers7

8

I think you're looking at it a bit backwards. Velocity is an after-effect of the work your team is doing. It is not a causal factor - ie. it's something you measure and it's not something you can directly tweak.

This explanation of velocity has a relevant tidbit to your question.

The simplest way to define velocity is: the number or user stories a team/project can do in one sprint

And by that definition, a longer sprint means more time for development per sprint and therefore a greater velocity number.

Relative velocity between a 2 week or a 3 week sprint is a slightly different question. Overhead from project ceremonies can impact how much you can get done because there is less overall time available. Consider this calculation as a way to identify available development hours in a sprint.

DevHoursAvailable = ((HoursInDay * DaysInSprint) - CeremonyOverhead) * AvailabilityFactor * NumberOfDevs

CeremonyOverhead is generally fixed. Decrease your DaysInSprint and you can see how you'll have less available time for development during that sprint. Using a simple example of 1 dev, here are the numbers for a few sprint lengths.

1 week:
((8 * 5) - 4) *.8 = 28.8 hours or 5.76 hours per day.
2 weeks:
((8 * 10) - 4) *.8 = 60.8 hours or 6.08 hours per day.
3 weeks:
((8 * 15) - 4) *.8 = 92.8 hours or 6.18 hours per day.

The "obvious" answer is that longer sprints are better. The problem with the obvious answer is that it ignores the beneficial impact of feedback loops. Temper thoughts regarding that calculation with an overall perspective on what Agile is supposed to bring to the development process.

I suspect your core issue is that your user stories are not as defined as they could be. That lack of understanding what's required is the real impediment to getting work accomplished.

7

On the other hand, there are a lot of disadvantages such as ceremonies (planning, retrospective) and so on

This a major red flag. If you see it as ceremony rather than essential vehicle that serves the working process and its improvement, probably working on that has more gain than fiddling with sprint length.

The process is in your (meaning the team) hands. You're supposed to chase the best-looking ideas, if need experiment and adjust. We were doing 2-weeks then eventually switched to 3 weeks and it worked better. But sometimes just set the length based on the estimate for the scope. Yeah, I'm aware of the "equal length" idea, but it's not a dogma, and may not really fit with some real-life project. And having a clear and evident sprint goal may serve better.

The proper length is really not something that can be deduced from outside. You are there to know the relevant factors. At the planning you can start with "ok, what can we do in next X weeks". Or instead "what would be the next sensible increment". In any case planning up the latter is good, then look what time it would take. And portion that in one or more sprints.

Balog Pal
  • 1,721
  • 9
  • 16
2

Up to you. Try both, see what works. Use that.

The best agile 'sprint' I ever used was 6 weeks. We got so much done - but we only needed to deliver to the client on that schedule. We didn't use tasks, preferring working to the user-story style of working.

gbjbaanb
  • 48,749
  • 7
  • 106
  • 173
1

It depends on what you describe a "new team".

Indeed, a teams velocity depends on a lot of parameters among many (ie: juniors?, seniors?, newcomers?, tensions between team members?, etc.).

Therefore the "ideal" sprint length is also bound to these parameters.

Anyway, there's no out of the box solution for that, the only way is to test it with the team itself, and also take in account the best average fit for all the team members.

Vincent
  • 11
  • 1
1

I question your suggestion of a "shorter feedback loop". Your team should be working with your customers on a daily basis--feedback should not wait for the Sprint Review and Retrospective. Test, code, design, and get feedback immediately.

I personally like the three week sprint because the middle week allows the team some "flow" time. That is, there is always so time revving up the first week (learning what the heck these new stories mean) and some wrapping up the last (prepping for the review). A middle week to simply produce working software is a really nice thing to have.

Taking this logic further, four week sprints would make even more sense. However, the sense of urgency can be lost if you start extending your sprints. Moreover, there really is a relatively small chunk of information a person or team can grasp and hold in their conscious thought at one time--the longer the sprint, the more stuff you are trying to focus on, which can make things harder rather than easier. Also, it's harder to judge what external factors will creep in if you extend things too far out.

Matthew Flynn
  • 13,495
  • 2
  • 39
  • 58
1

Since you asked about a new team, I wanted to add some thoughts. I have been working with Scrum and other Agile methods for over 15 years and now I always recommend that new teams start with 1 week long Sprints. There are three critical reasons for this:

  • Shorter Sprints help teams get to a high-performance state faster. Long Sprints usually mean that it takes 18 months to two years to get to that state. Short one-week Sprints help a team get to that high-performance state in just two or three months. Of course, other things need to be in place as well to get to high performance (see "The Wisdom of Teams" by Katzenbach and Smith).
  • As others have mentioned, a shorter Sprint increases the feedback cycle. A one week long Sprint seems to be optimal for most teams doing software development or product development. The feedback should mostly be during the Sprint Review which should take the place of your traditional UAT process.
  • Finally, shorter Sprints put pressure on your team to deal with organizational obstacles to frequent delivery. That pressure is very uncomfortable at first, but is essential to improving your overall development processes including planning, compliance, releases, etc.

I wrote an article called 21 Tips for Choosing a Sprint Length that might be of interest.

Mishkin Berteig - Agile Coach
  • 11
0

The ceremonies have a purpose - when we recognize the purpose we realize they're not overhead but added value.

Planning - not just about committing to work, but also understanding how to work with your teammates. When people complain about a lack of collaboration in their Scrum Team I like to look at their Sprint Planning as part of the issue

Review - gather feedback from the customer about what we're building and is still relevant, etc. Also acts as a quality check.

Retrospective - improve the way we work together as a team.

When we put effort into honouring the deeper purpose the overhead problem usually goes away. As was noted in the original comments to the question the ceremonies generally scale linearly.

If you need more on the subject I have an article: Choosing a Sprint Length

Mark Levison
  • 109