Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
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 '13 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 '13 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 '13 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 '13 at 11:03
add comment

5 Answers

up vote 6 down vote accepted

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.

share|improve this answer
1  
That's not the issue at all. I really try to think, objectively, how to make such a desicion. –  Avi May 8 '13 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. –  GlenH7 May 8 '13 at 15:00
add comment

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.

share|improve this answer
    
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 '13 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 '13 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 '13 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 '13 at 12:28
add comment

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.

share|improve this answer
    
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 '13 at 13:43
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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