Skip to main content

Product Owner is prioritizing based on time estimate, rather than business value

Last post 04:01 am August 25, 2020 by Sean Hoegaarden
3 replies
06:15 am August 24, 2020

I work as a SCRUM Master in a Software Dev team that handles both production support tickets/ break fix tickets and also new features. 

This specific software product is a legacy system and the backlog refinement is often detailed. 

I have a Product Owner, that continues to ask for an estimate of task, mid sprint, in order to determine where that production support ticket will fits on the prioritised backlog for the next sprint.

For e.g, if the Tshirt estimate is either a Large or XL , then on occasions, he would avoid scheduling this higher on the Product backlog knowing that this would jeopardize other work on his backlog. 

My feedback is always to prioritize based on 'value', value to the customer and business. And for Production Support tickets, use the Cost of Delay method to determine the opportunity cost of not completing the task.

What are your thoughts?


07:04 pm August 24, 2020

Have you asked the Product Owner how he currently accounts for value, and tries to maximize it?


08:43 pm August 24, 2020

For e.g, if the Tshirt estimate is either a Large or XL , then on occasions, he would avoid scheduling this higher on the Product backlog knowing that this would jeopardize other work on his backlog. 

Are you sure that the Product Owner does not prioritize based on a combination of factors?

For example, if it is believed to require 1 day to deliver $5000 of perceived value, it might make sense to do this before investing 5 days to deliver $8000 of perceived value.

There could be other factors to consider, such as whether certain market opportunities or obligations are time-critical, dependencies between planned units of work, or validation of hypotheses to maximize the chance of building the right thing.


04:01 am August 25, 2020

" And for Production Support tickets, use the Cost of Delay method to determine the opportunity cost of not completing the task."

The thing is, calculating a more-or-less meaningful cost of delay for a bug which does not cause major disruption, costs a lot more than the delay itself.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.