Is the Product Owner a Team Member?

Product Owner Team Member
Scrum prescribes three roles:  Product Owner, Scrum Master, and Team Members.  The Team Members consist of developers, DBAs, QA people, and others who do the coding, testing, and other work to bring software to life.  Team Members rely on the Product Owner to provide information about requirements as well as to create and execute acceptance tests. If the Product Owner has such a key role in getting stories to “done”, then they become defacto members of the team.

Beware of teams that do not invite Product Owners to retrospectives, or where their participation in Sprint Planning is limited to a Q&A session at the start of planning after which they are asked to leave. These fly is the face of working collaboratively and building trust.

The key to making the Product Owner part of the team is for the Product Owner to recognize that while they will participate in several team actvities, they are only a team member up to a certain point.  There are lines that they should not cross.

Estimates

When the team is sizing stories or estimating tasks, the Product Owner’s role is to provide information about requirements but not to estimate the work.  It is very easy for a Product Owner who is trying to squeeze more into an iteration to pressure the developers into lowering estimates.  The Product Owner needs to recognize that if they are not doing most of the work on a user story by themselves, they should keep quiet about estimates.  The only exception to this is when they feel that something has been grossly overestimated because the requirements were misunderstood.  Otherwise, will the team really be committed when the developers know in their hearts that the estimates are unrealistic? Does this set stage for developing at an unsustainable pace?

Self-Organization

When an iteration starts and the team is determining how to approach the work, the Product Owner (just like the Scrum Master) must refrain from assigning tasks or dictating the approach. A self-organized team is an efficient and committed team. The Product Owner needs to let the team find its way for true growth and improvement to occur.

Retrospectives

When the Product Owner attends the retrospective, they absolutely must not assume an authority role.  It is not their place to lecture the developers, DBAs, or QA people about what they did wrong in the sprint. In all likelihood the Scrum Master has observed the same issues and will help the team through a self-discovery process that sets the stage for effective adaptation.

Reflections:

  • The Product Owner is a member of the team.
  • The Product Owner must understand that there are certain team activities (such as estimating) in which they cannot directly participate.
  • The Product Owner cannot exert authority over the team when acting as a team member.

Purposeful Personas and User Stories

The team was pumped to start work on the new Inventory SAAS product and eagerly anticipated the first user story writing workshop.  Bert, the product owner, had been doing a lot of up front work to make sure things got off to a strong start. The team was giddy and the room abuzz.

“Okay team, here are first stories that we should cover,” Bert announced as he displayed his list on the large monitor.

  • Inventory Quantity Forecast data column display on Item Details page
  • Customer Display page using name and address from mainframe CUST_DATA file
  • Web service calls to Forecasting system

The developers just looked at each other.

Aaron, one of the more senior developers, asked, “What is the big picture here?  What are we trying to accomplish with this system?”

“Oh, we are going to build a great new product.  I know what we need to do to beat the competition and how all of the pieces fit together so don’t worry about that.  I need for you to get this built as quickly as possible so I have been working hard to be as specific as possible with how the application should work and how it should look,” Bert explained.

Aaron asks, “Can you at least help us understand who the users are?”

Bert shakes his head.  “Don’t worry about that.  I know our users and I defined four security levels with corresponding page and data access rights.”  He displays the security levels on the monitor:

  • Guest
  • Basic User
  • Advanced User
  • Administrator

The team could start building the system with these security levels and these types of stories.  Bert could provide the exact details to the team and they could build according to those specifics.  But what would Bert and ultimately his customers be losing in working with his team this way?

A customer walks into a hardware store and asks for a drill.  Does he need a drill, or does he really need a hole in something?

On the surface, Bert is taking away the need for the team to think about what they are creating and whose jobs or lives they might improve. The team will not feel compelled to ask if there is a better way to accomplish Bert’s goals or if the product will be a good fit for the different types of proposed users. The team members will not have a sense of who they are truly working for. What if Bert instead had presented the following list of users/personas:

  • Inventory Clerk (high school graduate with basic computer skills)
  • Outside Sales Representative (moderate computer skills)
  • Branch Accountant (CPA – an advanced user)
  • IT Support (site administrator)

Now the team is in a position to better relate to the user base. Aaron asks, “Will the Outside Sales Reps need to access the application via a tablet?”

“Yes, of course.  The user interface needs to support the most popular mobile browsers in addition to the top desktop browsers,” Bert replies.

What about the user stories as originally presented? This product owner is setting the stage for his team to fall into a grind where sprint after sprint they are handed a set of stories to work on without understanding the larger purpose and meaning behind the stories.

What if the “Inventory Quantity Forecast data column display on Item Details page” had instead been written as, “Provide inventory forecast”?  This could set the stage for the product owner and team to brainstorm ways to make this information accessible  throughout the product in ways that could put them ahead of the competition. In the course of this discussion, the developers would gain a sense of purpose and commitment from their involvement in the approach and from realizing the significance of their work.

Creating this sense of purpose is one the product owner’s key motivational tools and cuts to the very core of what makes knowledge workers tick.  Product owners who do this effectively have energized teams that delight them and their customers with every sprint.

Reflections:

  • Craft a goal statement for each sprint – not just a list of stories
  • Write stories that describe the “what” not the “how”
  • Define user roles and personas, not just system security levels