Over the past few years, many large enterprises have adopted agile methodologies such as Scrum, Extreme Programming, and Kanban into their software development project management toolkits. Business leaders seem to resonate with the principles listed in the agile manifesto, such as welcoming changing requirements and delivering working software frequently. However, generic application of agile methodologies does not always fit nicely into the enterprise’s organizational environment. Managers often encounter obstacles when the chosen methodology conflicts with existing enterprise workflows.
In my experience working with clients of Acquia Professional Services, I have found tremendous value in customizing an agile methodology to fit the needs of the organization and project. One way to do this is by setting an appropriate sprint duration. Most projects will use two to four-week sprints, but some organizations may benefit from durations as short as one week or as long as six weeks. Lengthening or shortening your project’s sprint durations changes the project’s cadence, efficiency, reporting, and ultimately its chances for success.
Here are five organizational variables to consider when setting your sprint durations.
Stability of Requirements
Tune your sprint duration to the expected stability of requirements. Projects with more stable requirements can afford longer sprint durations. Fewer interruptions for product demos improves efficiency, as long as demos don’t reveal the need for re-work. If requirements are vague and expected to change, sprints of a shorter duration will be more efficient due to less re-work.
Strictness of Timeline
For the organization and the project, would it be worse to cut the project scope or delay the delivery timeline? If cutting scope is worse, plan for sprints of shorter duration to provide multiple opportunities for iterative demonstration. If the timeline is most important, numerous demonstrations might not be a good use of precious time. In these cases, align sprint durations with a feature freeze date, set by planning backward from a target launch date.
Project Team Turnover
Changing staff in the middle of a project is seldom planned, but it happens all the time. If you expect this challenge in your project, consider shortening sprint durations. Each sprint should conclude with a potentially shippable product, providing a stable baseline for onboarding new project team members. Shorter sprints also make it easier for departing staff to wrap up their contribution before leaving the team.
The nature of customers’ availability should also influence sprint durations. A customer’s constant engagement with the project is desirable, but often not practical. When customer interactions are limited and need to be scheduled far in advance, longer sprint durations can work well.
An agile team working in isolation can achieve amazing results, but progress is thwarted when the team’s work can be blocked by dependencies on outside teams. Also, the need for frequent communications across teams brings coordination challenges and too many meetings. Projects can cope better with high interdependence when sprint durations are longer and the need for cross-team coordination is less frequent. Of course, this idea can be taken too far, as in the case of some waterfall projects which reserve only the final moments of a project for integration testing of previously independent workstreams. Experimenting with sprint duration can help your organization finding the best balance between these extremes.
Setting the sprint duration for your agile project is a small decision with a large impact. It is just one of many methodology customizations you can make to ensure a project is set up for success within your organization.