Agile methods such as Scrum, Kanban and OpenAgile do not require long-term up-front plans. However, many teams desire a long-term plan. This can be thought of as a roadmap or schedule or a release plan. Agile planning helps us build and maintain long-term plans.
Agile Planning Process
The steps to do this are actually very simple:
- Write down all the work to be done. In Scrum these are called “Product Backlog Items”, in Kanban “Tasks” and in OpenAgile “Value Drivers”.
- Do some estimation of the work items. Many Agile estimation techniques exist including Planning Poker, The Bucket System, Dot Voting, T-Shirt Sizes. These tools can be applied to many types of estimation. There are three kinds of estimation that are important for Agile Planning:
- Estimating relative business value. Usually done with the business people including customers and users.
- Estimating relative effort. Usually done by the Agile team that will deliver the work.
- Estimating team capacity. Also done by the Agile team (this is sometimes called “velocity”).
- Create the long-term plan. Use the team capacity estimate and the sum of all the effort estimates to come up with an estimate of the overall time required to do the work. (In Kanban, which doesn’t have an iterative approach, this is a bit more complicated.) Use the business value and effort estimates to determine relative return on investment as a way to put work items in a logical sequence.
Agile planning allows a team to update estimates at any time. Therefore, the techniques used above should not be thought of as a strict sequence. Instead, as the team and the business people learn, the estimates and long-term plan can be easily updated. Scrum refers to this ongoing process at “Product Backlog Refinement”.
Principles of Agile Planning
In order to use Agile planning effectively, people must be aware of and support the principles of Agile planning:
- Speed over accuracy. We don’t want to waste time on planning! Planning in and of itself does not deliver value. Instead, get planning done fast and use the actual delivery of your Agile team to adjust plans as you go.
- Collaborative techniques. We don’t want to be able to blame individuals if something goes wrong. Instead, we create safe estimation and planning techniques. Inevitably, when an estimate turns out to be wrong, it is impossible to blame a single individual for a “mistake”.
- Relative units. We don’t try to estimate and plan based on “real” units such as dollars or hours. Instead, we use ordering, relative estimation and other relative techniques to compare between options. Humans are bad at estimating in absolute units. We are much better at relative estimation and planning.
Many teams that I work with choose their Sprint length without too much thought. Often enough, that’s okay and it works out. But, in some cases, it helps to think clearly and deeply about what length of Sprint to choose. Here are 21 tips on choosing a Sprint length.
- Don’t ever go longer than 4 weeks (one month)… if you do, by definition it’s not a Sprint anymore. The Scrum Guide is unambiguous on this requirement.
- Scrum is about fast feedback – shorter Sprints mean faster feedback.
- Scrum is about continuous improvement – shorter Sprints give a team more opportunities to improve.
- High-performance teams need pressure to form – shorter Sprints provide pressure.
- Each Sprint is, ideally, an independent project – longer Sprints may make it easier to get a potentially shippable product increment truly done every Sprint.
- “False” Sprints such as “Sprint 0” or “Release Sprints” may feel necessary if your Sprint length is too short – try to avoid the need for false Sprints.
- 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.
- 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.
- 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.
- Small failures are better than large failures, shorter Sprints help.
- 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.
- 2-Week-long Sprints are most common for IT and software product development.
- Most Scrum trainers and coaches recommend Sprints to be 1 or 2 weeks long.
- 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.
- If your team has trouble finishing all the work they plan for a Sprint, make the Sprint shorter. Shorter Sprints are easier to estimate!
- Every Sprint should be the same length for a given team so don’t let your Sprints get longer just to “get everything done”.
- Experiment with extremely short Sprints to see what is possible: 1-day long, for example.
- 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 Sprint lengths.
- If you are working on a product, consider Sprints that allow you to release minor updates more frequently than your main competitors.
- 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.
- When a team is new, shorter Sprints help the team learn its capacity faster.
Author’s Note: this is one of those articles where I thought of the title first and then worked to make the article meet the promise of the title. It was tough to think of 21 different ways to look at Sprint length. If you have any suggestions for items to add, please let me know in the comments (and feel free to link to articles you have written on the topic). – Mishkin.