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?

Improve this question
5
  • 1
    While planning and retrospective come more frequently, do you not also have 2/3 as much to talk about? And thus, can you not shorten the meeting?
    – pdr
    May 8, 2013 at 12:32
  • 3
    My experience with scrum shows that retrospective will take as long as it can. Planning might be a little shorter but I'm not sure that enough. Also, there are the demo to the clients/po and sprint-review meeting.
    – Avi
    May 8, 2013 at 12:36
  • 2
    That leaves two possibilities. 1. Your retrospective was, perhaps still is, too short. Don't see that as unproductive time, because it boosts your productivity the rest of the time. 2. Your retrospective lacks structure and isn't achieving much. In which case the solution is obvious.
    – pdr
    May 8, 2013 at 12:40
  • 1
    About 1 - I don't tend to agree that it was short. People in my team just love to talk :) We try keep focused but often it happens that the discussion drifts to a places where nothing productive will be resulted. Time-framing the retrospective helps cutting such discussion and get back on track to a productive discussion with clear conclusions and action items for the future. Regarding 2 - I agree and I have investigating ways to improve our retrospectives lately. Mabye I'll open a different question for retrospective.
    – Avi
    May 9, 2013 at 11:03
  • 1
    @pdr: There is a fixed cost to each meeting (e.g. before and after an interruption you are not going to work on anything serious). Therefore, fewer meetings can be more efficient than lots of short meetings.
    – Giorgio
    Aug 14, 2014 at 6:07

7 Answers 7

Reset to default
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.

Improve this answer
3
  • 1
    That's not the issue at all. I really try to think, objectively, how to make such a desicion.
    – Avi
    May 8, 2013 at 13:57
  • 2
    @Avi - my speculation aside, you can now look at the quantitative effects of different sprint lengths. Simply plug in the appropriate numbers for your team regarding overhead and your utilization factor. From there, you have a balancing act between the length of the sprint versus the impact upon the feedback cycle. For that matter, Agile encourages doing things differently to constructively experiment and identify means of improvement. Change your sprint lengths for a while and see what the results are.
    – user53019
    May 8, 2013 at 15:00
  • 3
    You said "CeremonyOverhead is generally fixed." Shouldn't your sprint rituals scale with the size of your sprints? This article claims "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." which might be a bit optimistic, but it should be close to linear.
    – sgryzko
    Aug 12, 2016 at 8:57
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.

Improve this answer
1
  • 1
    I agree with your diagnosis. Meetings will be kept short, simple and effective by an experienced team. Long meetings that the team tries to avoid are a sure sign of a broken implementation of agile.
    – Sklivvz
    Jun 4, 2013 at 13:43
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.

Improve this answer
4
  • I know it's up to me and each team has its preferences. Yet, I wanted to gather some dos and don'ts to make a good decision already at the beginning. Btw. In this 6 weeks sprint project - you had more than one sprint?
    – Avi
    May 8, 2013 at 12:14
  • 6 weeks seems a lot for a sprint, maybe too much. I think that, in most situations, if you go beyond 4 weeks with a sprint, you're probably doing it wrong...
    – Radu Murzea
    May 8, 2013 at 13:45
  • I think that gbjbaanb had only 6 weeks for the project. Or in other words - the project was only 1 sprint. Of course, even a 6 weeks project can be divided to 1-2-3 weeks sprints.
    – Avi
    May 8, 2013 at 14:00
  • we had about 6-8 months of work to do. It just so happened that 6 weeks was good for us and the client who reviewed our deliveries, and that's the point - ignore anyone who says what a sprint should be. Its what makes you most productive. Remember, agile says deliver working software regularly, it does not say 2 weeks. I've worked on 2-week sprints where we had to do a lot of research to make the delivery, at each end the demos were embarrassing in their brevity, and the feedback from them was inconsequential. So we had a lot of overhead for little result. YMMV
    – gbjbaanb
    May 9, 2013 at 12:28
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.

Improve this answer
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.

Improve this answer
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.

Improve this answer
0
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

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.