Product Owners in an Agile world are expected to prioritize the user stories by business value. By using business value they shall assure that the whole team is working on the most important things in respect to reaching the business goals. But how exactly this should be done is something that I never found a satisfying answer for.
As a ScrumMaster I think if an Agile team is expected to inspect and adapt their processes to maximize the business value they deliver each sprint, they should know what this business value thing is and how they can measure, estimate and asses it. Here at Immobilien Scout we now invented regular business value estimations to have clarity and transparency about the business value we deliver and that is how we do it. I’d like to hear your feedback 🙂
Once a week for an hour, each of our service lines will have a business value estimation meeting. A service line is an organizational unit which contains a few cross functional teams with their team leads, Product Owners and ScrumMasters working together on the same function aspect of our real estate portal. We have a service line “Search” for instance providing all the functionality for the real estate seekers on our portal.
The business value estimation meeting is done by the Product Owners of the service line and representatives of the development teams. We call that meeting the product board of a service line. This product board is estimating the business value of new epics and assessing the estimations of those epics which already have been delivered.
All starts with one of the Product Owners introducing to the product board a new epic he prepared. He explains what business value he wants to achieve with this epic. To make this easier and not completely arbitrary we defined four classes of business value drivers.
So if the Product Owner aims to increase the revenue of the product with the new epic, he would choose “growth” to be the value driver. As you see we have explicitly defined value driver classes for areas that are not directly related to money. But of course investing in learning and quality is needed to make money in the future 😉
After the value driver for the epic has been named the Product Owner comes up with the KPI like 50.000 EUR for revenue (Growth) or -10% page load time for performance (Customer). We want to have explicit and quantitative KPIs, so that it is easier to check if and how good we achieve the business value goals for the epic.
Both decisions the value driver for the epic and the KPI are then discussed in the product board and often the suggested KPIs or the value driver are challenged. This is intended of course to enable the service lines Product Owners and team members to have a shared understanding of the purpose of an epic.
Now comes the cool part, the estimation of the business value. After the product board agrees to value driver and KPI, the estimation is done exactly like you do the story point poker game with the development teams, so the business value estimation is based on comparing the business value of the epic to those epics which already have been estimated.
Most likely the product board will not have an agreement immediately and you will have valuable discussions about the business value of an epic just like you would have it when you discuss the complexity of a story. When the estimation of the epic is done we have a clear and transparent decision about what we want to achieve with it, how we will measure the success later and we know how valuable this epic is in comparison to other epics.
Finally our Product Owners are now able to do the prioritization of epics in a transparent way and for each service line we track the business value they deliver and provide charts for them to help them optimize for business value.