A key tenet of the agile software development process is that all work is divided into repeatable sprints. There are many forms of agile (Scrum, XP, etc.), each of which prescribes a different approach to structuring your sprints. While these approaches to agile can differ radically, several general patterns exist, which you can use to decide how to structure your team’s sprints. Most companies that I have worked with take the principles of agile development and apply them to their team’s unique culture and preferences. The result is a set of practices that fits for that software development team. This two-part post will provide some considerations for deciding how to structure your sprints.
It is critical to the agile process to have a fixed sprint length. The sprint is usually defined in a number of days. Work items are scheduled into the sprint in the order in which they need to be addressed. The highest priority items are started on Day 1 and the team works through items until the end of the sprint is reached, which we will call Day X. X is then the number of days in the sprint. The sprint period should rarely change and be recorded on your company’s shared calendars. Sprints will have distinct names and are usually referred to in ascending numbers. For simplicity, you can just start at sprint 1 and increment from there.
In terms of selecting the sprint length, as with many things, it depends. I don’t think that a particular sprint length applies to all teams and all situations. I do think there are some book ends – sprints need to be at least a week and shouldn’t be longer than a month. Sprint work also should align with the business week. The weekend provides a natural break in the work cycle, that also creates a strong dynamic around “starting” work on Monday and “ending” work on a Friday.
Determining the length of your sprints can be influenced by a few factors:
- The size and inter-dependencies of your team(s). If you have a small team (5 people or less), who do not have significant dependencies on other teams in order to finish their sprint work, then a shorter sprint (1 week) will work. If you have many developers on multiple teams contributing to the same sprint, the coordination overhead will be large enough to justify a longer sprint. Since this overhead is paid every sprint, developer cycles can be optimized by lengthening the sprint and including more items in the coordination. In this case, a 2 or 4 week sprint is probably appropriate.
- The breadth and complexity of the application. A large, monolithic code base will often require a large set of regression tests that must be run in order to verify that the code changes made in the sprint are ready for production. While automation can reduce the amount of time these require to run, if you have a complex, user-facing application that spans multiple device types, you will still likely have the QA team and product managers test the sprint’s release candidate manually before release. If this regression testing requires a day or two to conduct, then you will incur this cost on every sprint. In this case, a longer sprint makes more sense. On the other hand, if the sprint participants are contributing to a smaller, encapsulated application (or service without a front-end), then the regression testing requirements may be less, or even fully automated. This would allow for a shorter sprint, like a week. I realize that a four week sprint may be counter to the “move fast and break things” mentality, but there are many types of mission-critical applications where the final QA process must be thorough. A banking application would be an obvious example. In these cases, a longer sprint would allow a higher percentage of sprint time spent on development.
- The amount of overhead in your sprint release process. While you can perform production releases during the sprint, these are often done on separate branches, representing small fixes or activation of feature flags. The assumption is that your sprint ends with a substantial amount of code released to the production environment. If your change management or release process requires substantial time to actually plan, stage and push the code, then longer sprints would reduce this repetitive overhead.
Where you have leeway, I would lean towards a shorter sprint. The sprint length will set the general cadence for your organization and create the sense of urgency around how work is planned. A long sprint will naturally reduce that sense of urgency and the healthy pressure to complete items. Where you have time-consuming test requirements or an encumbered release process, look for opportunities to streamline and automate.
Sprint planning represents the activities that determine what work will be scheduled into a sprint. Most teams maintain a “backlog” of work items that they would like to address in the future. These can be product changes or technical debt. These items are prioritized by the product manager and team lead. As part of the planning process, the engineering team lead will apply a “cost” to each item. This cost is usually expressed in developer time (2 developers for 3 days). The planning exercise results in an agreed set of work items that will fit into the time available in the sprint.
There are a couple of items to think about as part of planning:
- When to conduct planning. Planning can be conducted within that sprint’s boundaries, where the team spends Day 1 of the sprint on planning. Alternately, planning can be performed during the final days of the prior sprint, and complete before the new sprint starts. I prefer to conduct planning activities outside of sprint boundaries. The reason this works is that the team lead and PM normally conduct this planning work, leaving the individual developers to continue finishing their sprint work. If your team is very flat, or your team lead can’t represent cost without developer input, then you might consider making planning a part of the actual sprint. In this case, you would allocate a day or two at the beginning of the sprint for everyone to work on planning.
- Balancing feature work with technical debt. Items planned for a sprint should not just represent product features. You should also pull in a healthy amount of tech debt in each sprint. In case you aren’t familiar with the term, tech debt refers to work items that improve the state of your infrastructure or code base. They usually generate a developer efficiency or create a new technical capability. They are often sponsored by the engineering team, versus the product manager. I usually shoot for a 2:1 ratio of features to debt in a sprint. The ratio between features and tech debt can vary from one sprint to another. In some sprints, your product manager may ask to knock out several high value features, pushing out tech debt items. Just remember to get the postponed debt addressed in the next sprint.
This post is continued in Part 2.