Agile development organizations will typically use sprints that are one, two, or three weeks in duration. In our experience at Quoin, the optimal duration of a sprint depends on the organization, team, and type of project. We have worked with clients that have successfully used each of these variations, and wanted to share a few guidelines on how to select the right sprint duration.
First, we should dispense with the notion of four week or longer sprints. Sprints provide the essential mechanism for planning and executing on a project because this cycle allows enough time to enable measurable progress. Yet, if the duration is four or more weeks, the project team can lose the ability to understand the scope and interdependencies of the effort. A four week sprint is just too much time and effort for most developers to track his or her progress in any meaningful way. An organization that wants to adopt such long sprints (really more like 10K or half marathon) is likely struggling with the fundamental concept of an agile development process, and is seeking a poor compromise between an iterative process and a genuinely agile process.
The 'right' sprint duration has to start from the decision about what constitutes a normal sprint. At a minimum, a sprint must include:
- Backlog grooming;
- Sprint planning;
- Development; and,
- Delivery of work products.
Please note that delivery could be review and acceptance of documentation or an internal build and release of the software. Thus, even a minimal sprint has activities that have to be performed to enable this iterative process. Backlog grooming (even when just done by the project and technical leads), plus sprint planning can take anywhere from 1/4 day to a full day of effort. The process of reviewing or completing deliverables can take a similar amount of effort. Moreover, a sprint might also include:
- Sprint retrospective; and,
- Stakeholder demonstration.
All these activities represent significant effort for a project team. Sprint planning and execution enable productive effort; yet, this necessary work can seem like 'overhead' that is not directly related to specific development tasks.
Our preference at Quoin is generally for two week sprints. This duration allows a normative sprint that includes the retrospective and review or demonstration with stakeholders. We believe this duration provides enough time to accomplish assigned tasks and to support the critical coordination that makes agile an effective development process. A two week sprint would likely allow a single member of the project team to accomplish significant progress – perhaps 15 story points or 9 ideal-days, depending on the estimation units used by the project team. A team of 4 developers therefore has a signficant amount of development capacity (e.g., 60 story points) in a two week sprint, but this duration is still easy to plan and estimate. In contrast, one week sprints seen too short given the planning and execution cycle, and a three week sprint becomes too much work to plan and deliver effectively.