Monday 4 August 2014

Release Planning Exercise

One of the key deliverables of an inception is a Release Plan and release planning exercise is one of the final activities of an inception. Release planning is quite an intense and engaging activity and takes nearly a full day to plan. The below picture is of a completed Release plan after a day long planning session. The release plan has 3 streams to start and the 4th stream starts later down the line. This release plan had releases slotted every 4 weeks with first release in 10 weeks. 






For me, this exercise is one of the most important aspects of an inception. Today I am going to talk about how I facilitate a release planning activity. Release planning needs a bit of preparation before the exercise can begin. The first step is to ensure that you have the following things ready before you call the team for planning
  • All the story cards written down on index cards. One story per card. Group them by features (see pic below). You can color code the cards for each feature to have a more visual effect. If you do not have cards you can use paper or post-it notes. Although index cards on table are the most easiest to move around. 
  • A long table for cards to placed. If long tables are not available, a long running wall with cards stuck using blu-tag (or post-it notes on wall) also works. But moving cards on a wall is a bit troublesome. Or you can just clear the area in the room and use the floor.
  • Iteration numbers written down on the top from left to write. The pink post-its in the below picture are iteration numbers







Once the first set of preparations are done, I call the inception team -  Devs, BAs, UX , QA (whoever has been part of the inception). I handover all the story cards that are grouped by feature to the team. The next task for this team is -
  • To identify feature they would like to play first. Key things to consider while deciding the first feature to play are - the feature with the most technical risk, or a feature that is needed to building the initial technical frame work or the one on which other features have most dependency etc.
  • Place the cards in a series and create the first stream of work.
  • Once the first set of cards are placed a similar exercise is repeated for the remaining cards. The  team tries to determine the next important feature they would like to play and place the cards as the second stream and so on. Any features having dependency are placed in a single stream as they cannot be played in parallel.
A particular feature might be split in to streams after the initial dependency stories are completed. You don't need to slot each and every story just do enough for first set of discussions to start. Below is a picture of one of the release planning activity we did. We slotted around 10 parallel streams as they were technically possible. 



How many cards are to be slotted per iteration, per dev pair is something that the development team decides. It is based on complexity of the stories, our understanding and based on our track record of how much we have accomplished in the past. In the above picture you can see that based on our track record and comfort of the devs, we had slotted 2 stories per iteration.

Below is another picture of the inception team busy in discussing how to slot the stories in different streams. If you look closely you can see a stack of cards with each person, these are story cards grouped by features.






I prefer placing these cards at the bottom and leaving some place at the top so stakeholders can move the cards from bottom to the top. Here is a pic of how the cards look when placed at the bottom leaving place at the top for planning with the stakeholders.







Once this step is done, you are ready for action. Now call your stakeholders and walk them through what you have done and why. Talk about what technical dependencies exists and why you thought a particular feature needs to be slotted first.
































Remember the main aim of the release planing activity is to define smallest possible, business relevant releases. Get your business stake holders to define small goals so that you can take things to market quickly.

Apart from deriving the aims of the release from the inception activities, I have found time boxing a great tool to get stakeholders think in terms of small and frequent releases.

Many times I have asked the customers to prioritize features that they want released first based on the assumption that money gets over by a certain time. Another option is to just draw a regular interval releases - like every 4 weeks or every 6 weeks and ask business to prioritize what gets released in that time frame. You can make this visual by drawing a line with a tape or a ribbon across the table at a gap of every 4 or 6 weeks

The key thing to remember is that business can only decide which stories get done, they cannot decide how many stories get done in the given time frame. This is because as development team, you know the capacity and pace at which your team will perform and business just gets to swap in and out stories and you as development team decide if they can be accomplished in the time frame and if the dependencies are taken care of.

You will soon realize that customers start discussing and start to move stories based on what they want first. Its an iterative process and you keep going through it discussing till all your stories are slotted. Here is a picture of stakeholders moving cards to prioritize requirements.





By the end of the session, you will have most of your stories slotted and releases finalized.  Below is a picture of a completed release plan. You can add different color post-its for key dependencies or mile stones. You can color code a feature by different colors to make it a lot more visual. In the below picture, we have 4 streams of work and then some dependencies added in terms of data & UX followed by a 5th & 6th stream which starts later down the line.






You can either slot all your stories or decide to slot only the initial one and then re-plan based on how things progress. The important thing to remember is that this is just a starting point for planning and release planning is a continues process and it keeps evolving as the project progresses. You can read more about how release planning can be used as continuous planning and tracking tool here

In one of the recent inception, we used a i-pad to record the entire release planning activity. Here is a quick 36 sec video that summarizes the whole day. Thank you Michiel for sharing the video :)