Skip to main content

How does a Product Owner contribute to make the Increment, Valuable !

Last post 07:22 am June 2, 2021 by JAYANTO BHATTACHARYA
No replies yet
07:22 am June 2, 2021

I believe in order to deliver the Value to the end user, it’s very important that before sketching the Product Goal, the Product Owner should practice Scrum Values & Empiricism to capture the core problem of the customer by shadowing the end users in order to understand the Trigger-Action-Reward i.e. where is the “Trigger” (requirement or problem), What is the “Action” taken (what action does the user take to fulfill the requirement or to solve the problem) & What is the opportunity that can be a “Reward” (How can IT play a crucial role to connect the dots).

Let’s understand it better with an enchanting example, a car mechanic often needs a new part to repair a car in his garage, here requirement of a new part by the mechanic is the Trigger. The mechanic knows which part is needed, it’s source of procurement & price and thus the mechanic takes Action by dialling every time to the dealer to know the availability and the current price. As the mechanic wastes a lot of time every day in dialling the dealer in order to know the availability & current price of the Product hence the Product Owner can see a clear scope of Lean where IT can act as a Reward by connecting the requirement of the mechanic with the source of procurement in a simple way by eliminating the waste of time & effort.

Related :  Why a delivered Solution may not always be a Value !

Indeed Scrum Values are also very helpful to a Product Owner where Product owner Focuses on the customer’s problems & requirements, Commits to the stakeholders to deliver Value in a Sprint, Opens to the Scrum Team with the Product Goal & the Product Backlog Items, Respects the feedback of both the Stakeholders & the Scrum Team & shows Courage to optimize the Value of the Product resulting from the work of the Scrum Team .

In fact the first litmus test of a Product Owner about practicing Scrum can be evaluated about how does the Product Owner capture the “End Users' problems and requirements” after detailed customer observation, engagement, & data analysis! If the Product Owner’s findings are either incorrect or insufficient, the whole Design - Development - QA could yield Volume based Increment over Value Based Increment at the end of a Sprint no matter how well the Scrum Team collaborates to develop a solution against those problems! Which could ultimately be a waste for the end user.

Even Scrum Guide clearly says that the primary objective of the Product Owner is to maximize the Value of the Product not the Volume of the Product, resulting from the work of the Scrum Team. In a research, it is found that about 65% among Product Owners still use old techniques to understand the problems & requirements of the end users therefore it’s a high time that a Product Owner practices agility by learning and adopting new simple techniques to observe the problems & requirements of the end customers in a more refined way. One another challenge is the close mind-set of some of the Product Owners where a Product Owner insinuates that to understand the stakeholders' requirement is enough to build the Product and thus to reach and shadow the end user which indeed incurs more cost & time is not needed. Hence, the half-baked customer observation & research by the Product Owner ultimately makes the developed Increment invaluable as the Increment doesn’t meet with the customers' expectations thus the hard work by the Scrum Team & the cost to the company goes in vain.

Related : How are Scrum Values interconnected to each other !

Another factor which is one of the reason for the Increment to become Invaluable; is the long distance & disconnection of the Developers with the end users. I believe, the Product Owner should break the barrier between the Developers & the end users by sharing all the discussion which the Product Owner had with the end users, may be via mail communication, telephonic communication or even question – answer chats so that developers also get an opportunity to come close to the customer and understand their requirements or problems in a better way.

Let’s gel with the concept with an enchanting example, imagine that there are 2 Pizza stalls where the 1st Pizza stall named Mini Waterfall Pizza Stall at Chicago city gets an order of 1000 pizzas from a Chicago Music Concert Company (Stakeholder) for their customers (end users) where the Product Owner evades the end users and just takes the feedback of the stakeholders. Finally analyses together with the Scrum Team & insinuate the taste which customers would like and therefore make & offer (push) innumerable pizzas (output) to customers based on customer perception but when most of the customers tasted it; they didn’t like the taste of the pizza hence the pile of pizzas becomes a waste (Lean).

RelatedWhy is a Scrum Master called True Leader in Scrum Guide 2020 !

While the 2nd Pizza Stall named Agile Pizza Stall at New York City gets an order of 1000 pizzas from a New York fashion event company (Stakeholder) where the Product Owner first observes and engages with the customers (end users) by asking some open questions like what sort of mouth-watering pizza did they have last time & what ingredients made those pizzas amazing. So after deeply understanding the customers’ expectation and aligning them with the stakeholders inputs, the Product Owner with the team take (pull) order & prepare pizza accordingly in order to offer the hot ordered pizza (outcome) on the customers’ plate which fits the customers’ expectations. Meanwhile it also unlocks an opportunity for the Product Owner to pull customers’ feedback to make pizza more palatable further.

So to keep the customers happy in order to retain customers and attract new set of customers, we need to make tasty pizzas (Value) over a pile of pizzas (Volume).

Therefore as a Scrum Master, I believe that if the Product Owner invests a good amount of time to Focus (one of the Scrum Values) on customer observation & data collection in order to capture the exact need or problem of the end users before sketching a Product Goal, 50% of the SDLC (Software Development Life Cycle) job is done. As I believe if the Product Goal is created by the Product Owner after a deep data analysis based on an extensive customer observation, the release of the increment aftermath of the development would be Valuable with a responsive Product Market Fit. So, how to "Do the right Work" is Product Owner's accountability while how to "Do the given Work, right" is the Scrum Team's accountability.

Related : Is your organization following Scrum or Mini Waterfall within Scrum Framework !

According to Scrum Guide 2020, the primary "Focus" (one of the Scrum Values) of a Scrum Team should be on cross-functioning & self-managing to deliver simple possible Value. An interesting point to jot down is, when a PBI (product backlog item) meets with the DOD (definition of done), an Increment is born, while an Increment can only be considered Valuable when it is simple & usable.That can only be possible when the Product Owner shadows the end users to deeply observe, engage, interpret & capture the end users' core problem & requirements.

Once the user's core problem & requirements are captured by the Product Owner and shared with the Scrum Team, the Scrum Team should conflict with each other over ideas & explore the untouched opportunities by diverging the problems & possible solutions and consecutively converging the problem & solution to deliver the Value in order to delight the customer as well as to consistently surge the Market Share, NPS ratio, Usage Index as well as to maintain an edge over enemies (rivals). Indeed, diverging the problems & possible solutions answer the question i.e. "Can we do it" while after diverging, converging the problem & solution answers the question i.e. "Should we do it".

  • Can we do it - Volume
  • Should we do it - Value


When the primary Focus to deliver the Value is achieved, then the secondary Focus of the Scrum Team should be on Velocity to deliver Value as the speed to deliver simple possible Value & its Release to market is also important to compete with the competitors.

As like Amazon which successfully executes CI & CD in every 1 sec where some customer in some corner of the world experiences something new in every 1 sec.

In fact, we are coding in the century where "Fast Fish eats Slow Fish" (Agile Start up can beat a non-agile big Enterprise) unlike the times of 2nd Industrial Revolution where "Big Fish used to eat Small Fish" so of course with Value, the focus on the Velocity to deliver Value is also the need of the hour.

Related : How much Agile mindset you have! Shows How much Active mindset you have !



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

Please note that the first and last name from your 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. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, 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 may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.