Agile Release Planning

Agile release planning helps team to answer the following questions about their project:

• What can customers expect?
• About when will they get it?
• And how much will it cost?

Done well it is useful tool for teams to define release themes/goals/objectives and explore early release opportunities so that they can get customer feedback and/or potentially earlier return on investments. It is also a great opportunity to do some team building especially with a distributed team. When I facilitate this event I typically include some fun team games I learnt from Simon McPherson(@SIMONMACPHERS0N and http://gamessimonplays.com/).

 

This post reflects useful tips I've gathered from facilitating these events with small (< 8) and large teams (> 50) across multiple industries (Software, Healthcare, Telecoms and Finance). It also reflects the wisdom I got from co-facilitating this event with many great individuals:

 

Plan for the Release Planning Event

• Identify a facilitator (Scrum Master or Agile Coach) for the event
• Have a Product Vision, High level goals and Objectives
• Ensure the product backlog is prioritized and relatively stable
• Check that the Team velocity is relatively stable (after 3 - 4 Iterations or so)
• Understand the key drivers for your project i.e. Trade-off matrix
• Note key event and their dates they may impact your project

 

Invite the right People

• Product Owner
• Scrum Master
• Team Members
• Domain Experts
• Architects
• Others (anyone that can help ensure your plan is a good one)

Have an Agenda for the meeting

• Establish working agreement for the event
• Product Owner presents product vision and roadmap
• Product Owner presents the project’s trade-off matrix
• Product Owner presents the prioritized product backlog
• Team asks questions to understand user stories
• Team estimates user stories at a high level (Affinity Estimating or similar technique)
• Team should split User Stories that are too large to complete within an Iteration or add new discovered ones
• Determine your MVPs/MMFs/MMFSs (Story mapping is a good technique to lay out what story set is needed to deliver value)
• Team reviews key dates, milestones and Sprint calendar
• Team discusses dependencies
• Team discusses plan risks and/or issues
• Team finalizes release plan showing what will be worked on in each Sprint and future release candidates
• Record any key decisions, assumptions, dependencies, risks and/or issues
• Team commits to Release Plan
• Product Owner communicates plan to Stakeholders/Management
• Meeting Retrospective

 Watch out for these

• Product Owner not the decision maker for your project? It will be difficult to negotiate your trade-off matrix, accetance criteria, MVPs if your PO isn't making the decisions.
• Diving into too much detail and complex design discussions: Save yourself! You will have at least two more opportunities to review each product backlog item before the team works on it (1) Backlog Grooming meeting and (2) Sprint Planning meeting

Communicate your plan to Management/Stakeholders

Your communication should include:

• Release plan: What are your deliverying and by when. Include Release candidates (MVPs)  you've identified.
• Key assumptions: State any assumptions your are making in coming up with your plan
• Dependencies list: Resolve dependencies before the team pulls stories into their Sprint backlog.
• Risks and issues: Note mitigation strategies and any adjustments to release plan

Don't let it get Stale 

• Review/Track/Update your release plan at the begining of every Sprint. The plan is only useful if you keep it updated and make adjustments based on new information from executing your Sprints

 Reference

1. Version One’s Agile Checklist.