A Coach’s Guide to Release Planning is part of the nice series proposed to Agile coaches by Samantha Laing and Karen Greaves. This book provides a complete plan to run a workshop where people can learn how to plan their release in an Agile way, a topic that should interest the whole Scrum team.
As the rest of the series, this book uses the “Training from the BACK of the room (TFTBOTR)” approach that splits each sessions in four “C” parts: Connections, Concepts, Concrete Practice and Conclusion. On this basis, the book proposes chapters that deal with product planning, roadmap management or portfolio prioritization. It discusses also techniques like story mapping and release burnup. As with all the books of Samantha Laing and Karen Greaves, the material is well structured and easy to read. This download includes the 4C template, Working Agreement Cards, the full Training Plans and the Slide deck.
From the developers to the product owner, all members of the Scrum team should be involved in planning and thus should read this book. The material will be also interesting for project and product managers that work in a context using traditional project management approaches.
Reference: A Coach’s Guide to Release Planning, Samantha Laing and Karen Greaves, http://leanpub.com/ReleasePlanning
Quotes
Some people have a misconception that teams MUST deliver a certain velocity, and that if they do not they should work overtime. If that’s the feeling in the room, try spend some time helping them see how this might impact things negatively.
Managers often add more people if capacity is not high enough, but they don’t realise this will actually reduce their capacity initially. If you need to grow capacity, make sure you can afford the lost capacity it will take to grow.
When Product Backlogs are just lists of items the relationships between them can get lost. Story Maps help everyone see how one detailed story relates to the bigger picture. Story Maps are created from a user or persona point of view, which usually means that the requirements they generate are more user focused. The biggest benefit of Story Maps is the line which identifies what is in scope for a release. Often without a Story Map people discuss features at a Step (green) level and agree that payment is needed. Breaking down what payment could entail, and prioritising each piece within that, can help stakeholders identify ‘non critical’ scope more easily.
Before coming up with a date, it is important to know what the team is capable of delivering. Most agile teams use story points and track a velocity each sprint. This is a great measure of team capacity and can be a very effective planning mechanism. Just beware that velocity is a predictability measure not a productivity measure.
There is often a misconception that agile means there is no plan. Plans do exist in agile, the major difference between agile plans and traditional waterfall plans is that in agile, we update the plan every sprint, and only mark items as done when they are 100% complete. There is no 95% done anymore. If there are project managers in the room, they are usually use to developers telling them things are 95% done, when in reality they are far from complete. This problem disappears in agile, as there is a binary state. A Product Backlog item is either 100% done or not done.