- As a product owner, you'll need to stay on top of when your product increment is ready, and when you're ready to release it. Getting the product prepared to go to market is what release management is all about. Release management is all about launching a product. Product should not be released on a whim. Good planning and management is required for a successful product launch. Release management covers, marketing, resource provisioning, launch activities, and financing. Great question. As I scrum our day of team figures at their velocity and their product backlog is filled, planning and product release becomes easier. Release can be aligned with sprints, this process is known as sprint mapping. Product backlog items or PBI's are matched with the day of team's sprint velocity. In order to do this, the product backlog must be filled ahead of time, usually three or four sprints ahead. Sprint mapping enables release management, and gives visibility to stakeholders of when items are expected to be released. Remember, the sprint mapping is a forecast; it's not a guarantee. There are a number of things that may affect a product before it's released. For example, what are the product's minimum releasable features, or MRF's. These MRF's have to be truly minimal. What features must the product have? Working to the MRF's helps speed up product development and nice-to-haves can be added in later increments. Product owners cannot allow everything to meet the release. What is the technical capability of the development team? If there are gaps in knowledge, can this be filled easily? What performance metrics can be checked? Does the development team have a consistent velocity rate? Or does it fluctuate? This alongside the backlogs and capacity of the team can help with forecasting the product. There are also more standard factors that are often considered as constraints. Budget, time and scope. This trio of constraints are often flexible or fixed. And these factors often determine the quality of a product. The table shows how these variables may impact a product. Having a fixed project scope, but a flexible budget and time to release means that the product must meet a fixed quality. Whereas having fixed scope, time and budget, means that whilst you may have a particular scope or product, the time and budget may exceed or not meet the criteria of the scope, meaning the product quality will be variable. Well, you can manage this with sprint mapping. Let's walk through an example. Let's imagine you're planning on releasing a mobile app in eight weeks time, and your srum team works in two week sprints. Start out with your ordered backlog. At the top of the backlog, you'll have your MRF all the way down to the might haves. A helpful method of ordering is using the MoSCoW Method. Must haves, what the product absolutely must have. Should haves, what it should have to make it, or the things that will probably make it to release. Could haves, the nice-to-haves. And won't haves, these are the whish list items that are likely to not make the product. When the items have been estimated and how much effort it will take to make, using user story points for example, calculate the day of team's average velocity, Using their ordered backlog of items, then draw lines after each increment of average velocity. Because you've already ordered the backlog in MoSCoW, you will then be able to calculate what features the product will have, by the time it's released. Here the product has all of the must haves, and should haves, and some of the could haves. This also works if you're working to a fixed number of user story points. The same process applies, but you set it against the number of story points instead of a particular date.