“At last,” I hear you cry, “finally, some planning.” Well, you have essentially been planning all through the feasibility and initiation stages; we just didn’t call it as such. This is evidence of iterative or adaptive planning—the art of only planning enough to achieve your immediate and most valuable goals. We’ll see later more about adaptive planning, but for now release planning is our focus.
Your release plan may well be determined by external events. Perhaps there is a trade show you want to demonstrate your app at, or your customers will get the most benefit using your app on the run-up to Christmas. These are timeline events that your goals may be aligned with. You would most likely plan to deliver user stories or features that make the most sense to facilitate these events. If there are no external dates that you need to consider, then you can just go with feature prioritization and delivering earliest what makes the most sense and delivers the most value to your customers.
· If you created a story map in initiation, this will help guide your release plan. Use it to identify your MVP, the minimum feature set that will get your product in the hands of your customers, start earning revenue, get feedback, and acquire more customers.
· The story map will help you carve out future releases too. But keep in mind that as you learn, get feedback, inspect, and adapt, future releases may change. So don’t plan in great detail.
· You may have from two to four releases in a 12-month period. Don’t do less, because your first release is your MVP and gets your foot in your door, after which you’ll want to iterate and release more features and bug fixes in a regular cycle. Don’t do more unless you’re performing well and have plenty of Agile techniques and tools in place to manage continuous delivery.
· Each release is a timebox which is broken down into smaller iterations. An iteration is a timebox. The timebox is one of the most important control measures in Agile.
· To size your release:
· Divide your release timebox by two. This will give you how many iterations you have. So if you have a release of 12 weeks, you get six two-week iterations.
· Then remove two iterations—you’ll reserve one for a “sprint 0” iteration and another for a “release” iteration. This leaves you with four development iterations.
· Work with your team and product owner to fill each iteration with stories, starting from the top of the backlog and working down. When the team thinks they’ve filled an iteration with enough stories they can realistically achieve based on their capacity in the two-week timeframe, repeat for the next iteration(s). Use the release plan and story map to guide what goes into each iteration.
· Do not plan the next release yet. You’ll do that as you near the end of the current release.
· Take the user stories from each of your iterations and add up the story sizes. So if your iteration 1 has 25 story points, but iterations 2, 3, and 4 have 10, 45, and 65 points, respectively, you will need to refactor. Target an equal number of story points in each iteration. This becomes your anticipated velocity—the amount of valuable “stuff” completed for each iteration.
· The team may not have worked together before. They are almost certainly working on a new problem or product. They will not perform at their best from day one. For this reason, your velocity may be volatile in the first few sprints. But as the team settles down, it should stabilize. Use this data to refactor your release planning which, in turn, helps you plan your product with a known velocity and confidence.
· If necessary, break stories into smaller chunks and resize.
· Your release plan, especially early in the life of a project and a new team, is only ever a guide. Do not treat it as a commitment or guarantee that all or these exact stories will get delivered as planned. As your team matures, work gets done and trust and confidence builds, so will the accuracy of your plans.
· Never force your team to “commit” to more than they are comfortable with. Trust their judgement and their expertise.
· Future release planning exercises will be simpler, because you’ll take the release size, multiply the number of iterations by your team’s velocity, and fill the release plan with the stories that add up to velocity multiplied by the number of iterations.
Consider this as an example. If you go to a restaurant to eat, you wouldn’t go ahead and order all the items on the menu and expect to eat it all in one sitting. You’d never be able to eat it all, you might not afford the cost, you’ll be sick of food, and the restaurant may close while you’re eating the fifth of 19 courses! You may not leave a happy customer, the restaurant may not find you to be a great customer, and the experience will be bad all around. More likely, if you love the restaurant, it’ll be because you enjoyed a lovely meal there once. You’ll decide to go back and enjoy a different meal. You’ll tell your friends, you’ll go there often. The moral of the story is:
· Plan your releases in small chunks.
· Consider your capacity.
· Don’t take on more than you can realistically achieve.
· Revisit the plan often to see what you can change and improve.
· Plan, execute, inspect, learn, adapt, repeat.
Release planning takes place often in a software project. Each new release requires a release plan. The release plan can also be refactored at any time during a project. Just take care to not overdo it and fall into zombified planning psychosis. At the end of release planning, you’ll want to prepare for the first iteration, which is where we’re happily going next!