How to Train Agile Product Owners Using Financial Terms

Helping product owners understand their role in the agile process can be difficult. Specifically, working with them to prioritize stories is hard when your product owner doesn't have exposure to development processes in their day-to-day work. The teams I've worked on have used a variety of methods to encourage product owner engagement, with equally variable levels of success. However, most recently I've been introduced to a process that uses financial ideas and terminology and seems to work very well.

The team I'm currently a part of typically groups our stories into three categories. First, we have our "committed" stories. These stories are selected by the product owner based on the number of points the development team has committed to completing within the sprint. Next, there are "extra credit" stories. This group includes stories that are not critical for the current sprint but are high on the product owner's priority list. If the development team completes the committed stories and has remaining time in the sprint, they start working through the extra credit stories based on priority. The third group of stories is the traditional backlog, which is prioritized by the product owner on a rolling basis, with new stories being put in order by rank after they're groomed.

At the end of the sprint, the development team meets with the product owner in a formal "show-and-tell" meeting to go through the stories that were completed during the sprint and present them for acceptance.

Once this meeting is complete, the real magic begins. Prior to the show-and-tell meeting, the development team discussed how much work they're comfortable committing to for the upcoming sprint. This is based on how many days of work there will be, how many hours of vacation time developers are scheduled to take, and any other known time bandits. The amount of work the team is committing to is called velocity and is expressed as a number. During the team's regular grooming sessions, they assign each story a point value based on the work involved, level of complexity, etc.

This is the part where some product owners get confused. We have to explain that we need them to tell us what to do next, ensuring that they think about what stories will be the most valuable for their long-term vision while still providing for whatever short-term needs they may have. It can be a challenging exercise.

But the team I'm on now has made a breakthrough: They put that exercise into financial terms, such as purchase, budget, cost, and investment—a set of words that everyone understands, no matter what their job or area of expertise is.

So, back to that planning session after show-and-tell. When the product owner walks up to the backlog to select stories for the next sprint, she is given the team's velocity, which we refer to as the “budget,” and then she "purchases" the stories she wants to have worked on in the next sprint. The product owner and the development team talk about how much each story will "cost," which one will be a better "bang for her buck," and what the value of each "investment" is.

These terms definitely come into play on most of the technical debt stories my team pitches to the product owner. One specific example that stands out is when the development team wrote a story to create a code tool that would handle converting reports to Excel files for export in a standard way. This tool, which they called the “Excel Helper,” would not provide any measurable business value when it was played, but it would provide significant reduction in the cost of future stories that required Excel exporting functionality.

The development team pitched the story to the product owner by explaining that this was going to be an investment in the project—it would not have any measurable return in the sprint that included the story, but it would show significant dividends in the future. They provided a few examples of stories that would be cheaper once this tool was completed.

The product owner trusted the developers and purchased the story as part of one of the early sprints in the project. In nearly every sprint after that, the Excel Helper provided some return on her investment. The developers were very grateful for the time to create a tool, and they reinforce the benefits of that decision as often as they can. Incidentally, other teams within the company are now using the Excel Helper, thus providing savings to other agile projects, too (something we’ve made sure to let our product owner know).

In some cases, during sprint planning, the development team may ask that the product owner purchase a more expensive (higher-point) story because it'll pay off the extra work repeatedly over the long run, as we saw with the Excel Helper. Other times, they tell the product owner that it really doesn't matter and the cheap (low-point) story can be played without any negative effect in the long-term cost of the project. In this way, the development team helps the product owner ensure that she is spending her “money” in the most effective ways possible.

Just like in any financial decision, the basic logic of “Is this worth that much?” gets played out in the sprint planning ceremony. This ensures that the product owner and the development team are both on the same page about the project’s priorities and general direction.

While story points can be loosely tied to actual dollars and cents, it is not the point of this exercise to make that connection. We work hard to make sure that everyone in the room, from developers to the product owner to business analysts, knows that these are metaphorical dollars and cents. The idea is that by using financial language everyone is familiar with, we can help the product owner make wise choices and have honest discussions about how to accomplish both long-term and short-term goals in the most efficient way possible.

Framing the discussion in this way seems to automatically put the product owner on the right track, thinking about what value each story provides and how critical it is to her priorities. It also provides a common vocabulary to use with all the various stakeholders to minimize confusion and aid in the prioritization process.

While each team has its own language and process, using financial terms has greatly aided my team in our communication with project stakeholders, specifically product owners. It reduces much of the confusing "tech speak" that development teams tend to fall back on, and it unifies business, development, and financial project stakeholders so that they can all communicate quickly and clearly about priorities and reasons for those prioritizations. Using financial terms also provides an innate understanding of the impact of specific stories on the final project, because a story that is scored higher has a higher impact on the project while a story that is scored lower has a lower impact.

Think about what terms you use with your project stakeholders and product owners. Would using financial terms make that communication process easier and clearer for you and your team?