A release plan is an extremely important negotiation process. It should be factual, considering dependencies, anticipating risks and sharing with your Product Owner concerns, plans to improve the product in non functional requirements (e.g. QA, Security, Performance, etc.). You are managing expectations, challenging how reliable is the predictability of your Dev team. But should you only consider your MPP? How can you avoid emotions in the release planning process?
Some posts ago I already explained the concepts of Minimum Viable Product (MVP) and Minimum Possible Product – check the post: Do you know your MPP?
But I would like to return to those fundamentals, to share some thoughts and techniques to make your release planning process more efficient. We can describe it all in 3 main phases:
Phase 1 – When your Product Owner expresses his ambition,
When your Product Owner expresses his ambition, his wish list for that release. If it’s a brand new product we normally call it the MVP.
Phase 2 – The Dev Team estimation
This is a task done together with the Scrum Master (if we do Scrum) or with the Delivery Manager (if we do Kanban). During this process Dev Team will estimate the effort to implement the Product Owner’s wish list.
We will not have risk to commit with the release if our MVP is equal to our MPP, but we must assume dependencies were already considered in the MVP total effort calculation.
If you don’t do it regularly, your capacity will not reflect this factor and you will have a higher MPP than what is the real one.
If you don’t consider dependencies regularly in your estimations, what I recommend you is to estimate them together with the epics. So you can estimate Epics and sum them with the estimated story points for dependencies.
In this phase, I would like additionally to leave some considerations regarding:
– Estimation Units – if normally you estimate in Story Points, please keep doing it during the release estimation. Switch between estimation units will not help you to get more accurate results.
– Consider Non functional stories – remember that the major part of Product Owners are not aware of non functional stories that are mandatory for product implementation, operations, maintenance, performance, quality and security. It is part of the Dev Team or Scrum Master role to defend this capacity.
– Block capacity for the legal mandatory stories.
I’m sure if you do this recommended exercise, probably you will realize that your initial MPP will be reduced and than you need to enter in a negotiation process with your Product Owner. You must be ready and supported by facts in this normal capacity within the release time to deploy the highest value for the product.
Phase 3 – The negotiation process between Product Owner and Dev Team
I recommend to start this negotiation process trying to understand the individual value of each Epic for the product or for the release.
- Is this Epic bringing competitive differentiation to the product?
- Our competitors already have this feature?
- Are our internal processes or productivity being affected?
Explain to your Product Owner how you are estimating your effort in Story Points. They should know what are translating story points – see my previous post: How abstract really are story points?
Try to complete this matrix together with your Product Owner:
In the x you will have your implementation effort in story points (output from phase 2), in the y you will distribute epics value for the release or for the product.
Depending on the positioning of the ideas we should decide for:
- Go – Low implementation effort – high value for the product/ release
- Investigate – High implementation effort – high value for the product/ release
- Quick Wins – Low implementation effort – Low value for the product/ release
- and No Go! – High implementation effort – Low value for the product/ release
Bear in mind that you should consider implementation stories to comply with legal duties out of this evaluation but blocking capacity to do them.
Other advice is don’t start immediately all possible Epics. Too many activities in parallel are not efficient. Multitasking kills productivity. We should only start development once we have available budget and resources.