21 Tips on Choosing a Sprint Length

Referred URL - http://www.agileadvice.com/2014/06/12/howtoapplyagile/21-tips-on-choosing-a-sprint-length/

1. Don’t ever go longer than 4 weeks… if you do, by definition it’s not a Sprint anymore.
2. Scrum is about fast feedback – shorter Sprints mean faster feedback.
3. Scrum is about continuous improvement – shorter Sprints give a team more opportunities to improve.
4. High-performance teams need pressure to form – shorter Sprint provide pressure.
5. Each Sprint is, ideally, an independent project – longer Sprints may make it easier to get a potentially shippable product increment truly done every Sprint.
6. “False” Sprints such as “Sprint 0″ or “Release Sprints” may feel necessary if your Sprint is too short – try to avoid the need for false Sprints.
7. If you have lots of interruptions that are disrupting your Sprint plans, shorten your Sprints to match the average frequency of interruptions… and then just put them on the backlog.
8. If you feel like you team starts out by working at a leisurely pace at the start of a Sprint and then “cramming” at the end of the Sprint, then shorter Sprints will force the team to work at a more even pace.
9. Don’t lengthen your Sprint to fit the “size” of your Product Backlog Items… instead, get better at doing “splitting” to make the items smaller.
10. Small failures are better than large failures, shorter Sprints help.
11. If you are using Agile Engineering practices such as TDD, you should probably be able to do Sprints that are 1 week in length or less.
12. 2-Week-long Sprints are most common for IT and software product development.
13. Most Scrum trainers and coaches recommend Sprints to be 1 or 2 weeks long.
14. Teams go through the stages of team development (forming, storming, norming and performing) in fewer Sprints if the Sprints are shorter.  E.g. 5 Sprints if they’re 1 week long, but 20 Sprints if they’re 4 weeks long.
15. If your team has trouble finishing all the work they plan for a Sprint, make the Sprint shorter.
16. Every Sprint should be the same length for a given team so don’t let your Sprints get longer just to “get everything done”.
17. Experiment with extremely short Sprints to see what is possible: 1-day long, for example.
18. If you are doing a project with a fixed release date/end date, then make sure you have at least 6 Sprints to allow for sufficient feedback cycles.  More is generally better which means shorter Sprints.
19. If you are working on a product, consider Sprints that allow you to release minor updates more frequently than your main competitors.
20. Sprints need to be long enough that Sprint Planning, Review and Retrospective can be meaningful.  A 1-day Sprint would allow a maximum of 24 minutes for Sprint Planning, 12 minutes for Review and Retrospective each.
21. When a team is new, shorter Sprints help the team learn its capacity faster.