Estimate | Collaborate | ‌Plan | Communicate

As anyone involved in delivering large complex software programmes understands, when it comes to release planning, the map is not the territory. The real world of software delivery has unexpected gullies, crevasses and the occasional unseen mountain. In this blog I want to talk about a technique called Collaborative Release Planning (CRP),which is a simple planning method designed to give everyone a map to help navigate the terrain ahead of them. 

I first discovered CRP when working on a project rescue for a customer with our CEO Thomas. Effectively, it’s a planning tool that’s highly organised, yet flexible enough to handle fast-changing environments with multiple stakeholders. It’s now my go-to release planning process; it’s been battle-tested on numerous large programme deliveries over the years and it’s been pretty reliable to about 3 months out – with not a gantt chart in sight! 

The benefits of release planning

It’s crucial to define expectations around key project releases so that we can plan and communicate accordingly.

Collaborative Release Planning is an effective approach to planning out the next 2-3 months of work. It is designed to facilitate sessions between teams and other key stakeholders of an organisation, and provides a simple and transparent method of communication for release planning.  Because of its highly collaborative nature, CRP provides a great opportunity to achieve alignment and transparency.  

While Epics and stories will already be in the backlog, this style of release planning looks at user recognisable journeys and provides a sanity check for any planning activities.

Why is Collaborative Release Planning so effective?

The benefits of CRP in an organisation are wide-reaching. Here are just a few:

• The close collaboration helps achieve alignment with stakeholders.
• User recognisable journeys are highly visual and easy to update and communicate.
• It gives high visibility on dependencies and projected feature releases.
• Going through the process acts as a sanity check for any existing plan, which can then be tested against story-based backlogs.
• You’ll gain an independent view of your roadmap and release plan that’s distinct from the estimations and story point models that many stakeholders find difficult to understand.

What you need to know about CRP

What you need

The beauty of this release planning template is that it’s not rocket science! Anyone can do it, with very simple resources. All that is needed is a large table (big enough to see and easily manipulate all the tasks involved in the release), pens, post-its and index cards; or a digital equivalent.

How to use Collaborative Release Planning

Preparation

With the Product Owner, create your vision, goals and strategy for the release window(s). Then, working with the Business Analyst(s) and Product Owner(s), group the requirements into user recognisable journeys on index cards. Add only one journey per index card; these cards will represent an entire journey.  

Next, create columns on a table representing one calendar week in your release window.  Now create swimlanes in the first column.  Each swim lane represents a pair of developers working together.  The number of swimlanes is equal to half the number of developers, rounded down.  For example if you have 15 developers on your team you would have 7 swimlanes representing pairs of developers with one swimlane possibly showing 3 developers.  

You should now have a grid of weeks and developer pair-swimlanes.  Each block on the grid represents a pair-week, which is how long two developers working together would take to complete a journey.

Then introduce the concept of a roadmap and its parts to all participants. Working with your team, go through the following steps: 

1. Estimate items to be completed

Estimate each journey in pair-weeks.  On the journey’s index card write down the estimated weeks to completion; some journeys will be able to fit into a single pair-week, others will span multiple pair-weeks. 

• Use a simple ½, 1, 2, 3 and 4 to estimate recognisable user journeys.  
• Any estimate taking up 4 pair-weeks should be looked at more closely, and possibly broken up into smaller elements.  
• Use a zero (0) for journeys that by default will be achieved organically through other user journeys.  It is important to visualise 0 estimated benefits as part of the template, because although they will form part of the release there is no specific work to be allocated.

2. Confirm vision and roadmap

Review the vision and roadmap to confirm that everyone understands the overall goal for the product.

3. Place your cards

Lay down your recognisable user journey index cards on the table in a single column, in a rough order of priority. These should be placed separately to your grid for the time being. 

Now, based on these priorities start adding cards to the grid, beginning with week 1 of swimlane 1, i.e. the top left corner.  If a card was estimated to take 1 pair-week, it takes up 1 grid block.  If it was estimated at 2 pair-weeks, then lay this card plus a blank card next to it to represent the second week.  Remember, each column represents one pair-week.  As an example, if a card is 4 (pair-weeks) you would lay down the index card in the next available block of the grid and add 3 blank cards next to it (4 cards in total).  

You can also merge swimlanes by splitting an index card among swimlanes where that makes sense.  For example a 4 pair-weeks estimated recognisable user journey could have 2 of its index cards in swimlane 1 and 2 index cards in swimlane 2, indicating that 2 pairs of developers will be working on the same user journey together. 

4. Priotitise items

As you are placing your cards, discuss the cards on the table taking into account priority, possible release schedules, and logical work groupings. Here’s where you begin to see the real value of CRP, as you order and rearrange cards until you reach the best workable solutions for your business. 

As user recognisable journeys are highly visual and easy to understand, review with key stakeholders.  You will be surprised how effective a communication tool this is. 

Getting the most out of Collaborative Release Planning

The following are some tips and tricks we’ve learned through using CRP to ensure it works effectively for your organisation:

• Like all planning sessions, it’s important that pressure isn’t put on developers to cut the estimate down simply to comply with management expectations
• Involve key stakeholders so they can ‘see’ how their journeys will unfold, when value will be released and have realistic expectations around timescales
• This tool is most useful up to around three months out
• Don’t get hung up on the estimation part of the process – it should feel lightweight and fast
• If you’re unsure about the estimated time, round up rather than down
• Try to keep the largest estimate to 4 pair-weeks. Anything longer will usually benefit from being broken down into smaller journeys
• Keep in mind that release planning is an iterative process to match goals and their timings with the required features (based on their value, effort and dependencies)
• When sequencing the release plan consider dependencies, risk, value, etc. 
• Remember that when creating the release plan there are various levers you can operate to impact the outcomes:
  • scope (doing less)
  • quality (doing it at lower level of fidelity)
  • time (moving the overall milestones)
  • capacity (adding capacity or re-shaping resources)‌

Good looks like

When CRP is used effectively, this is what it looks like:

• Rooted in vision and context (why)
• Value centric (focuses on benefits and outcomes)
• Realistic and achievable
• Journeys grouped so that all stakeholders can understand what is being delivered 
• Recognises complexity and dependencies
• Reflects multiple (journey) releases within the plan
• Stakeholders (including the team) understand the priority and value created and are confident (at the time of creating) that the plan is achievable
• It is understood that the release plan will evolve and that given timings are indicative

 

And yes. The alternative, Collaborative Release and Planning appeals to my 5 year old self 🙂