Simply put, release planning is a process in which we determine what order we should implement the User Stories from the Product Backlog. Remember that our aim is to create customer satisfaction through early and continuous software delivery, the first Agile principle. When creating a Product Backlog, it's easy for it to become a bit of wish list. Blue-sky thinking happens as part of any requirements gathering process, regardless of the technique used.
Release planning allows us to prioritize the User Stories; the aim of prioritizing a Product Backlog is to surface the stories that will bring the most value and satisfaction to our customer first.
It's entirely plausible that your Product Owner has already prioritized their User Stories. If not, the following are a couple of ways that the team can prioritize the backlog together.
If you do choose to prioritize as a team, who should be present? Well, you'll need your Product Owner. If the Product Owner would like to include key stakeholders, you should include them. Finally, I would recommend including the entire team. I'm always surprised by the amount of information about a product that surfaces during release planning, and your team will benefit hugely from hearing it.
The following activity is a group approach to prioritizing User Stories:
Activity: MoSCoW
What you'll need: The Product Backlog deck, post-it notes, black sharpie pens, and Spare index cards
Setup: A large table to work on that the whole team can fit around
Remember: Set a time-box before you start
MoSCoW is a simple but effective way to prioritize the backlog based on business value and risk. It is an acronym that stands for:
M: Must have this
S: Should have this, if at all possible
C: Could have this if it does not affect anything else
W: Won't have this time, but would like to in the future
The Must User Stories are non-negotiable—if you don't deliver them, then the product won't work and it will be a failure. It's nice to have features classified as either Should or Could. The Won't classification doesn't mean that you won't ever build this functionality, it just means it won't be part of the first release.
The simplest way to play MoSCoW is to set up the table in the following way:
Follow these steps to release plan and prioritize the backlog:
- Lay all of the User Story cards out on the table and give people time to familiarize themselves with the User Stories. Set a time-box appropriate to the number of stories. This step can be fairly social, people may share stories, or even read them aloud.
- Next we prioritize the stories, you should ask people to silently work and move the User Stories into the categories they think are the most relevant. Again, set a time-box for this.
Some stories will get moved and then moved again. Most stories will end up in the Must category to start with, and the table will likely look as follows:
If this situation does arise, remind people that this isn't in the best interests of the product's development. While User Stories marked as Won't may be equally important as those in the Must category, deferring some work allows the team to get on with other features sooner. To help this thought process, you need to think about which features might deliver the most business value or will reduce risk and uncertainty the quickest.
Ask the team which User Stories in the Must category can be moved down while still producing a coherent first release. Ask for suggestions of which stories you definitely Won't need, and then place them in Won't. Remind people that this is just for the first release.
After two or three iterations, you should see something like this:
Take the opportunity to review the User Stories and make sure you have a coherent set of stories for the Must swim lane. If it helps, order the stories from left to right in their logical sequence. The User Stories in the Must swim lane are your first release. While this won't necessarily represent a complete set of features, once built, it will give you enough to gather good feedback from your customer, and as such, will act as the beginning of your product's life cycle.
Another fun way for the team to work is with Buy a Feature. Buy a Feature is a game where team members are each given a certain amount of money. You start by pricing all of the features, making sure that some are more expensive than one person can afford, and only a group can purchase them.
The object of the game is to decide as a team which features you deem most important for your product and need to buy. To do this, you have to collaborate and pool your resources. This game and how to play it is detailed in Luke Hohmann's book, Innovation Games.