A popular technique that many Product Owners in Scrum adopt from another Agile approach, eXtreme Programming, is Release Planning. Release Planning still includes the act of refining items on the Product Backlog. This includes receiving input from Subject Matter Experts, customers, stakeholders, etc. Further refinement occurs, however, in Release Planning as these items are brought to the team or teams who will perform the work on them.
The team members ask questions about meeting the Definition of Done and any subsequent criteria that users have to ensure that the item(s) will be accepted. The teams then size the item as it relates to other items they have worked on and will be working on. This popular relative sizing technique is called Story Points. It should be noted that Scrum teams may use whatever sizing technique they choose as long as they remain consistent with the technique and their Sprint length remains consistent.
Once a Scrum team has completed one Sprint worth of work, they will have a data point known as Velocity. Velocity is not a performance measurement of the team, but rather is a planning metric for the Product Owner and Development Team to be able to better determine what they can pull into the upcoming Sprint. The longer the Development Team is together, planning becomes relatively easier based on the number of data points that have been gathered.
This enables a Product Owner to produce a Release Burndown chart:
The Release Burndown chart shows whether a particular date will deliver the desired scope based on the current trend of the work being done. It uses the total number of points in relation to the number of sprints it will take this team, based on their velocity, to deliver all of the items. The Product Owner can choose to adapt, removing scope to see what affect this has on the Release Date. Subsequently, they can add scope. As long as the Development Team has sized these items, they can see what affect adding the scope has on the date.
If there is a desire to not cut scope but to achieve an earlier date, there may be a temptation to simply add more people to the Development Team. This is risky as more people are not instantly more productive. And people cost money so costs will inevitably go up. If the people added do not assimilate well into the team, there is a risk that Velocity will go down and stay down. If there is more money available, it may be worth adding another team to work in parallel to pick up traction to reach an earlier date.
Want to learn more about Release Planning? Join us for an upcoming CSM or CSPO Course.