A Product Owner read up.

A small reading covering the role of the Product Owner in agile teams.

What does the theory says about the Product Owner’s role?

The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is the sole person responsible for managing the Product Backlog. Product

Backlog management includes:

· Clearly expressing Product Backlog items;

  • Ordering the items in the Product Backlog to best achieve goals and missions;
  • Ensuring the value of the work the Development Team performs;
  • Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
  • Ensuring the Development Team understands items in the Product Backlog to the level needed.

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a backlog item’s priority must convince the Product Owner.

For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says.
(Scrum guide | http://www.scrum.org/Scrum-Guides)

-+-

The primary goal of a product owner is to represent the needs and desires of the stakeholder community to an agile delivery team, being the first source of information about the problem domain for the team.

Each agile team, or in the case of large programmes an agile subteam, has a single product owner to go to for information and prioritization of their work and they do so right away.

A secondary goal for a product owner is to represent the work of the agile team to the stakeholder community. In traditional terms, a product owner is in many ways an empowered business analyst without the burden of the bureaucracy surrounding big requirements up front (BRUF).

The role of product owner was introduced to the agile community by Scrum, although the onsite customer practice of Extreme Programming (XP) is very similar. This role has been adopted by the Disciplined Agile Delivery (DAD) process framework.
(The Product Owner Role | http://www.agilemodeling.com/essays/productOwner.htm)

-+-

The product owner is commonly a lead user of the system or someone from marketing, product management, or anyone with a solid understanding of users, the market place, the competition, and of future trends for the domain or type of system being developed.
(Learning Scrum - The Product Owner | http://www.mountaingoatsoftware.com/scrum/product-owner)

How to recognize a good product owner?

Collaborate with the team on an ongoing basis and to guide and direct the team.
Empowered, and present.
(Being an Effective Product Owner | http://www.scrumalliance.org/articles/44-being-an-effective-product-owner)

Passionately about the customer of the product.
(Who Makes a Good Product Owner |http://geekswithblogs.net/rakker/archive/2010/05/17/who-makes-a-good-product-owner.aspx)

 

What are the needed capabilities for a Product Owner?

A good product owner is a good negotiator.
(Who Makes a Good Product Owner |http://geekswithblogs.net/rakker/archive/2010/05/17/who-makes-a-good-product-owner.aspx )

Understand the technical decisions
(Transitioning to Scrum: Selecting the Product Owner | http://www.construx.com/Retrospectives/Transitioning_to_Scrum__Selecting_the_Product_Owner )

A thorough understanding of the customer needs
(Being an Effective Product Owner | http://www.scrumalliance.org/articles/44-being-an-effective-product-owner )

Planner
(Skills a good Product Owner should Master | http://blogs.agilefaqs.com/2012/05/26/skills-a-good-product-owner-should-master )

Knows the organization.
(Qualities of a great product owner| http://www.scrum.nl/website/scrumblog.nsf/dx/7-qualities-of-a-great-product-owner )

 

How to recognize good work from a product owner?

The first artifact of an agile to look at when you want to know how they perform is the Backlog, and investigate if it is nice, clean and mature. If you want to know if the Product Owner is in trouble the backlog is also the place to look. Are there enough backlog items, are they well specified, are there acceptance tests etc …and are there backlog grooming sessions, with the product owner?

The goal of the UED (and anyone else involved at the time) is to add detail to the story in a just-in-time manner. There is usually no value to splitting a large user story up now or stapling a document to it if we won’t work on that product backlog item for quite awhile. While working to add detail in a just-in-time manner, those doing so should strive to add just-enough detail that no individual item will take more than one sprint to complete. Just-in-time and just-enough become the targets for establishing a smooth flow from product backlog to sprint backlog.
(Writing the Product Backlog Just Enough and Just In Time | http://www.scrumalliance.org/articles/87-writing-the-product-backlog-just-enough-and-just-in-time)

Sometimes called StoryTime sessions, the purpose of these meetings is to make improvements to the Product Backlog.
(How to Hold an Effective Backlog Grooming Session | http://www.scrumalliance.org/articles/339)

Grooming the product backlog should be a collaborative effort that involves the product owner and the development team
(GROOMING THE PRODUCT BACKLOG | http://www.romanpichler.com/blog/product-backlog/grooming-the-product-backlog/)

What are the challenges when mixing roles or transform a role to Product Owner?

It's important to understand that a piece of work can be done better by one whole person than by two half persons. Merging roles can lead us into strange situations. But Scrum guidelines clearly state that there are three roles: product owner, ScrumMaster, and development team. Scrum also demands 100 percent commitment from each of these roles. So if we merge roles, then it's simple: We aren't using Scrum. We should always mix our primary colors at 100 percent, rather than using uneven amounts of a variety of colors, to aim for white. We should not live with gray.

( Why Not Merge Roles in Scrum? | http://scrumalliance.org/articles/524-why-not-merge-roles-in-scrum )

Developer as Product Owner:

Developers like to develop features, technical challenging features. Beside that you see these challenging features bubbling up the backlog also the challenge will be the low level acceptance criteria, just due to the optimistic and code view of the developer.
Trigger: Technical Items on Backlog, Scope Creep.

Testers as Product Owner:

Testers can be good critics of the backlog quality. For example, questions will be asked if the backlog items are good written down and if they have good clear acceptance criteria. Beside the quality view also a good understanding of the product and users will make testers an interesting mix with the Product Owner role. A pitfall can be that too much design up front, will testers want to tackle most of the unknown upfront.
Trigger: big too detailed backlog.

Manager as Product Owner

It should be interesting to have your manager as a Product Owner. But for sure it wouldn’t be a good idea. Probably the knowledge of the product will be low. But more important the manager is your boss and when the boss wants something else you as a team member will probably listen although it is out of the sprint.
Trigger: interference in the sprints

Business Analyst as Product Owner:

You often see that analysts is the Product Owner or that they become the Product Owner due to a missing Product Owner. Although they understand the system / product into detail, this isn’t a good idea. For analysts models / documentation are their primary artifact and often also single point of truth. This often results in the diagrams being the master over the backlog, which results in too many documentation and other challenges.
Old habit: communicating via documentation
(Where Do Product Owners Come From? | http://www.agilemodeling.com/essays/productOwner.htm )
Trigger: diagram first, too much documentation.

End user as Product Owner:

The end user knows what he wants, but this doesn’t make him immediately a good Product Owner. A Product Owner needs to be available for the team all the time and needs to make visionary decisions with technical knowledge, something an end-users can miss during their daily work.
Trigger: missing in action Product Owner, Scope Creep.

Scrum master as Product Owner:

Problems may arise when the PO is being pulled by the customer in one direction that is causing significant strife to the developers (because they need to build some other infrastructure first). The SM job is not to follow the whims of the customer but to protect the developers from their whims. Pulling this off objectively is hard.
(#in comment: In Scrum, why shouldn't the Product Owner and ScrumMaster roles be combined? | http://programmers.stackexchange.com/questions/106966/in-scrum-why-shouldnt-the-product-owner-and-scrummaster-roles-be-combined )

The Product Owner cannot be the Scrum Master. They both have clear interests and habits. Changing their individual habits is hard. Changing them so they can see both points of view is impossible. They first have to learn the new way of doing their job with agility.
(Product Owners not proxies | http://kenschwaber.wordpress.com/2011/01/31/product-owners-not-proxies/)
Trigger: sprint interference.

What are the most common problems with Product Owners?

There is a big list of common Product Owner problems, for example when he is not available or that he doesn’t have the power to make decisions, or … see below a list of blog posts which covers them.

AVOIDING COMMON PRODUCT OWNER MISTAKES | http://www.romanpichler.com/blog/roles/avoiding-common-product-owner-mistake/

Product Ownership Antipatterns, or a character description of the PO from Hell | http://agile.dzone.com/articles/product-ownership-practice

Open Space Notes: Building a Better Product Owner | http://www.scrumalliance.org/resources/357

Your Product Owner Is Missing in Action — Now What? | http://www.scrumalliance.org/articles/509-your-product-owner-is-missing-in-action--now-what

 

Product owner training

Professional Scrum Product Owner Training | http://www.scrum.nl/training/Professional-Scrum-Product-Owner-Training-110224

CSPO: An Introductory Course for Product Owners | http://www.scrumalliance.org/pages/certified_scrum_product_owner

 

Add comment


Şarkı Sozleri