A lot of agile literature stresses that product owners must prioritize the delivery of value. I’m not going to argue with that. But I am going to argue that product owners need to optimize over a slightly longer horizon than a single sprint.

A product owner’s goal is to maximize the amount of value delivered over the life a product. If the product owner shows up at each sprint planning meeting focused on maximizing the value delivered in only that one sprint, the product owner will never choose to invest in the system’s future.

The product owner will instead always choose to deliver the feature that delivers the most value in the immediate future regardless of the long-term benefit. Such a product owner is like the pleasure-seeking student who parties every night during the semester but fails, and has to repeat the course during the summer.

A product owner with a short time horizon may have the team work on features A1, B1, C1 and D1 in four different parts of the application this sprint because those are the highest valued features.

A product owner with a more appropriate, longer view of the product will instead have the team work on A1, A2, A3 and A4 in the first sprint because there are synergies to working on all the features in area A at the same time.

Agile is still about focusing on value. And it’s still about making sure we deliver value in the short term. We just don’t want to become shortsighted about it.

Would you like to include comments?

Tagged:

About the Author

As the founder of Mountain Goat Software, Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile. Mike is a founding member of the Agile Alliance and Scrum Alliance. He is also the founder of FrontRowAgile.com, an online agile training website. He can be reached at [email protected] or connect with Mike on Google+.

First a comment on something that wasn’t your actual question: I think it’s great to do what I understand you to be doing in allowing a team to focus on a logical set of things before moving onto the next set of logical things. To me that doesn’t matter whether the decomposition is on technical or functional boundaries. But—speaking as at least somewhat still a bit of a programmer—there are times my head is into something and I want keep it there. Call that functionality A1. It’s nice if my product owner let’s me then work on A2 and A3 rather than working A1, B1, C1, then A2, B2, etc. as long as there is not a big drop in value between B1 and A2. Usually the synergies of letting a programmer keep their head in what they’re doing make up for the drop off in value if the items are small enough.

As for your actual question: If I understand it correctly, my view is that a team should always have a single person they go to for their overall product decisions. That’s the product owner. The product owner does not need to be the fount of all knowledge. But the product owner should be one person who ultimately makes the decision. A good product owner can say, “I’ve decided Thing A is important but go get the details on Thing A from her. And next we’ll work on Thing B and he’s the expert on that so talk to him about that.”

I somewhat equate it to being the president, prime minister or such of a country. And being in the US, I’ll use the president. [And as an aside, this is in no way a political statement. I’ve made the same comment when it was President Bush and I’ll make it again about whoever follows President Obama!] The President does not need to be the smartest person in the room about every topic but the President is the ultimate (final) decision-maker. Sometimes, I’d expect a good president to say, “Hmm, I don’t know, let’s see what my Secretary of Education has to say…” or “Let’s hear the Secretary of Defense,” and so on. Ultimately, though, the product owner, just like the President, makes the call. But the product owner may say “go talk to my Secretary of User Account Management” for info on how that part of the system works.

In terms of scaling this, we often then do see what I think you’re calling “team product owners.” Those team product owners should be accountable to the product owner for implementing the chief product owner’s vision.

Posted by Mike Cohn on 2015-07-20 23:01:43

Thanks Mike for another post about product ownership. Formally we tackle the issue defining system requirements and break them down into user stories. The system requirements represent the long term vision. Knowing that we'll rarely ever complete a system requirement in one sprint, we're forced to groom these well upfront with the team and decide which stories to deliver first. The biggest challenge (mistake I made) is not to define these stories as technical parts of 1 user story but really break down into user stories. It requires a different kind of focus than the technical breakdown which is natural to a team of engineers.Nevertheless, there are lots of lingering stories that are the result of singular requests by users or their representatives. These I will somewhat artificially group into "system requirements" and discuss with stakeholders in terms of timing. It's easier here to kick out or bring in isolated stories. It's close to what a software release is, but I try to group them according quality, performance, process efficiency, ... so that the group of stories has a similar goal.Still, this is not yet a real long term vision. In my case, I'm somewhat dependent on conversations my stakeholders have with actual customers or top management. In a big organization, it's not so easy to have the full "product ownership".It leads to another question: should a product owner be a "team product owner" with multiple products built or maintained by the team, or a "product product owner" with the risk that one team has multiple product owners, which are effectively turned into stakeholders and the scrum master taking up the PO role then. We work with "team product owners" which favours the team's focus but goes at the expense of the PO's focus.

Posted by Knotwilg on 2015-07-16 06:29:30

That sounds great, Imran. Thanks for sharing it. It sounds like you’ve got a great product owner.

Posted by Mike Cohn on 2015-07-06 16:11:47

Hi Mike, Good point. One thing I have observed is that having a sprint goal which is in line with the over all product vision really helps. In our sprint planning sessions the PO sets the sprint goal, keeping in mind the over all product vision and we pick the user stories together (that we can complete) according to the sprint goal. This sprint goal is defined in terms of incremental shippable product which helps group the most valued features together. This seems to be working very well for us.

Posted by Imran Qazi on 2015-07-05 22:29:05

Thanks, Pete.

I always recommend considering both risk and reward (cost and benefit) so I’m glad to read you saying so, too. I’ve gotten some heat for that over the years here—people have insisted that it’s sufficient only to consider the benefits of a feature. I’ve countered that doing so would also put cars like Ferrari, Lamborghini, and Bugatti at the top of our lists of cars to buy. Yet, very few of us drive those—because of the cost/benefit ratio.

Posted by Mike Cohn on 2015-07-05 19:30:25

Great point. And that’s one of the things I coach product owners to be aware of in prioritizing.

Posted by Mike Cohn on 2015-07-05 18:16:45

Great point - and all the more reason teams must be close with their Product Owners. POs aren't going to always recognize the synergies that can be had by preventing context switching. I also like to use the concept of product themes - the idea of focusing a period of time (a month, or a quarter) on a specific theme for a product. This can help guide feature prioritization and be a great communication tool for both team and PO.

Posted by Hustleberry on 2015-07-05 10:46:07

Nice point Mike. I would however say you need to consider risk / reward. Yes maybe by rearranging the items will in the long term be better for delivery and focus on specific areas, however there may be other external drivers enforcing the particular order such as deadlines / marketing . Not to dissimiliar ito how you decide to incur *some* tech debt

Posted by Pete Gore on 2015-07-03 05:55:10

Nice phrase, Tushar. That’s a good way to think about it. Thanks.

Posted by Mike Cohn on 2015-07-02 00:33:40

Nice phrase, Tushar. That’s a good way to think about it. Thanks.

Posted by Mike Cohn on 2015-07-02 00:33:40

Hi Mike,

That's a very good thought. In my opinion, "Thinking Big, Acting Small" will allow the Product Owner to have a clear vision on the medium to long term objective of the product, and at the same time focus on one sprint at a time in more detail.

-Tushar

Posted by Tushar Paunikar on 2015-07-01 23:43:29

Thanks, Özmen. And great point about product owners owning the product not just the coming sprint. That’s a great way to remember the difference. Thanks for that.

Posted by Mike Cohn on 2015-07-01 23:30:38

Hi Badri—

I’ll need to write a different sometime on cost of delay. Mostly I think it’s a horribly misnamed approach as usually taught because it’s not just cost of delay that is being considered. It’s usually a formula of that plus other things.

Posted by Mike Cohn on 2015-07-01 23:28:45

Hi Mike, A very good point which you have focused. It is also related to systems thinking from the perspective of viewing over a longer optimized horizon that helps to increase the value of the product. Additionally, you also need to focus on the cost of delay that can sometimes completely change the ordering of the user story in the backlog..What are your views on this aspect....

Posted by Badri N Srinivasan on 2015-07-01 11:14:30

Hi Mike,

I totally agree. We are not Sprint Owners, we are Product Owners. Let me tell you how I failed last year.

As a PO, I have focused too much on next sprint. Upcoming sprints were too broad. When I clarified issues in next sprint and team thinks issues are READY, I felt I completed my mission. One day, I realized, I missed the whole product vision. We were not delivering maximum value possible in product. We have prioritized issues only in the next sprint. We were missing more valuable issues as you told with an example. (A1, B1, C1 and D1) We were filling the available spots in the sprint with "low value issues". We never could groom during a sprint. We could groom only after a sprint completed.

This year, we are practising User Story Mapping. This approach enabled us to see the whole product easily. But we still need to groom backlog. Thank you for reminding what we own, the product!

Posted by Özmen Adıbelli on 2015-07-01 05:33:52

Hi Gurpreet--

Agreed. Some companies think being agile means they can change any time. There is (almost) always a cost to change. What we try to do is reduce the cost of change. The lower we can make the cost of change, the easier it is to avoid locking things down.

Posted by Mike Cohn on 2015-06-30 21:00:31

Hi Mike,

I agree with the discussion points mentioned in the blog. Unfortunately, these days a lot of companies believe in 'always changing' with the context of 'being agile' which is an incomplete and incorrect interpretation. In this context, long term vision will be difficult for the Product Owners. What do you say?