Scrum Roles: Product Owners and Team Members

The following is an extract from our book, Scrum: Novice to Ninja, written by M. David Green. Copies are sold in stores worldwide, or you can buy it in ebook form here.

Unlike a scrum master, whose responsibilities are focused on the development team, a product owner has a shared responsibility to the team and to the customer. The product owner is the voice of the customer, and stands in as the representative of the customer’s needs, wants, and expectations.

A product owner usually belongs to a department such as Product or Customer Support, and spends time working with customers directly to understand their needs and translate these into clear descriptions that the team can estimate and work on, using a consistent format we call stories in scrum terminology.

The product owner keeps an eye on the big picture from the customer’s perspective, looking at the overall state of the product and the timeline for release cycles, and the changing technical landscape, while deciding what features are the highest priority for the team to work on in the next sprint.

Product owners work directly with designers to make sure user experience flows have been considered, and that design assets are ready for the team. They also work with QA engineers to verify that the necessary acceptance criteria are accounted for in the test suite for a story. Product owners also collaborate with the scrum master to help remove blockers from outside the team that may be getting in the way of progress.

At the same time, the product owner works closely with the team to decide whether a desired feature is technically achievable, given the practical constraints of the team and the technology, and to plan out the sequence of stories based on their historical development velocity and their feedback about the product. Being close to the team is vital, since a product owner needs to be available so developers can ask about details of a story and confirm the progress of their work. Product owners also usually attend all of the scrum rituals.

Warning: One Person Should Not Be Both Scrum Master and Product Owner

One person shouldn’t try to take on the roles of scrum master and product owner simultaneously. A product owner has a duty to the client or customer first, and usually isn’t part of the engineering department. The objectives of a scrum master center around sustainable productivity, and these may not align with the organizational objectives of anyone reporting outside the department.

Responsibilities

One of the most critical duties of a product owner is clarifying the needs of the customer, developing a backlog of product features to work on, and writing clear stories that communicate the full expectations for the product, while meeting the standards of the team. A well-written story needs to encapsulate the full intention for a distinct slice of functionality, including any acceptance criteria, as well as the customer’s justification for needing this particular feature. Usually the product owner and the scrum master will collaborate to make sure each story is ready for the team.

Once enough stories are written to occupy the team for the upcoming sprint, a product owner keeps track of them and organizes them to make sure the sequence of development for the product is planned out efficiently and to the expectations of the customer. Meanwhile, the product owner is diligently working on stories that may be needed if the team runs out of work in the current sprint, as well as outlining and drafting items that reflect the customer’s anticipated needs for sprints in the near future.

A product owner doesn’t need to do detailed planning more than a sprint or two ahead of what the team may be working on. In fact, stories written too far in advance of the sprint in which they might be worked on are so frequently discarded or rewritten that it’s usually a waste of time to spell them out in much detail. But a good product owner maintains a vision for how the product will evolve as individual features are added, keeping in mind the importance of setting the stage in the current sprint for features that may be needed in the future.

Product owners need to be in regular communication with the customer, to make sure the stories they’re writing and the backlog they’re grooming meet current expectations. While scrum encourages transparency, not all teams invite customers directly into the rituals and artifacts. A product owner translates the state of the product for the customer—demonstrating and getting approval for each slice of functionality delivered—and gathers feedback from the customer to let the team know whether or not they’re on the right path.

In addition, the product owner needs to be available to the team to help resolve any conflicts or clarify any details about stories the team is working on. As the internal voice of the customer, the product owner needs to embody the expectations for the product, and be able to make decisions quickly so the team can continue working.

Day in the Life

Product owners split their time among several responsibilities and constituents:

meeting regularly with customers to share information about the team’s progress and gather feedback about what the customer wants next
working directly with designers to plan and prepare assets for the team
getting technical approval from the team for stories in development
verifying the completeness and relevance of the QA test suite
coordinating with the scrum master to make sure everyone has the information they need to do their work
meeting with team members when asked to clarify issues and make decisions
writing stories and grooming the product backlog so it reflects the current vision for the product.

Most product owners like to attend the team’s daily standup ritual. As guests, product owners are generally not permitted to ask questions or give feedback until after every member of the team has presented, unless asked directly. After the standup, product owners will often follow up on issues that were raised during the standup with the relevant parties, either on the team or outside.

While the team is working on the current sprint’s stories, the product owner is constantly watching their progress. It’s the product owner’s prerogative to adjust the order of the stories in the current sprint if it appears that a critical slice of functionality is in danger of not being completed soon enough. The product owner may also prioritize the backlog of stories that are ready for the team to start work on if they run out of stories in the current sprint.

Product owners need to spend their days ready to answer questions about the stories that are in progress during the sprint. When a product owner can’t be reached for a quick answer, the developers working on a story may be permanently blocked. For this reason, many product owners prefer to work alongside the team, so they can be available at a moment’s notice.

One of the things customers love about working with agile development teams is frequent and accurate information about the state of the product. Often a product owner is in daily communication with the customer to report on progress and get insight into any issues that may be on the customer’s mind.

When they aren’t assisting the team or the customer, product owners are writing and refining stories for the next sprint, grooming the backlog of stories to meet the customer’s vision for the product, and working with designers to make sure that everything the team will need to work on for these stories will be ready for them.

Team Members

Most scrum teams consist of a set of four to eight engineers. Their specializations should be planned to support the type of work the team is going to be responsible for, so they can estimate it well and produce results that meet the team’s definition of done.

A team member is expected to participate actively in all the scrum rituals, and operate in a transparent way that allows everyone to be at least peripherally aware of what their teammates are working on.

Cross-Training

Specialization is important to the development of an engineer’s career, but on a scrum team it isn’t assumed that any one engineer will have exclusive responsibility for any particular aspect of all stories. Part of the power of scrum is the transparency it provides, allowing engineers from all backgrounds to learn about what’s involved in developing any aspect of the work the team has accepted.

Scrum encourages engineers to work together. A practice called pair programming, adapted from the agile technique known as Extreme Programming, is often practical for the type of work done in web and mobile projects. Pair programming advocates matching people with different levels of experience to work together on the same code, so each can benefit from the perspective of the other.

The advantage of this approach is that the knowledge about what the product is doing, and how to develop every part of it, is shared across the entire team. Silos of information that reside only in the head of a single engineer are discouraged, in favor of communication with others. Not everyone is expected to be an expert in all areas of the product, but everyone should be prepared to work together with the experts on areas outside of their usual comfort zones.

The result is that the work may appear to go a little slower at first, as people come up to speed. But soon a deeper shared context will develop, which will speed up both estimation and development. The team will also become more resilient in the event that someone wins the lottery and decides to retire. There won’t be a gaping hole of knowledge left behind. There may be large shoes to fill, but at least there will be people who have some understanding of what was involved.

Note: Pair Programming

Pair programming is very demanding. Some of the expectations are that two people share a single monitor, and trade responsibility for entering code (driving) and keeping track of what needs to happen next (navigating). A pair should be talking with each other constantly as they work, and neither member of a pair should allow distractions such as email to interfere with the process. Most pairs find they can work no more than six hours a day in this mode, but the productivity gains and the benefits to the stability of the team are worth the tradeoffs.

Responsibilities

As far as the scrum process is concerned, a team member is responsible for the quality of the product being developed, and for the preservation of the scrum process for the entire team. These are two aspects that every team member has the authority to affect by the way they perform their duties.

The quality of the product is supported by the team’s ability to accept or reject stories. If stories are presented that aren’t fully clear, or that may be impossible or impractical given the history of the project, the team should put the quality of their work first and insist that the product owner rewrite or retract the stories.

Estimating the effort involved in doing the work to complete a story is also part of the team’s responsibilities. As a team works together and gains experience with different stories, they should begin to develop a shared and subjective scale of relative effort involved in stories of a similar nature. The effort, usually measured in arbitrary points, is assigned by the team to help establish how much work they can do within a timeframe. That helps the product owner plan how quickly new features can be completed.

The team is expected to push back against any attempts to sacrifice quality for the sake of speed, given the practical constraints of the project. Additionally, the team should be tracking the overall quality of the codebase, and proposing stories that would refactor the existing code to enhance maintainability, or to support emerging technical standards. Keeping the code clean, self-documenting, and internally consistent helps everyone on the team work together more effectively.

Every member of the team is also responsible for maintaining the scrum process for every other member. If anyone interrupts the standup, or tries to introduce changes to a story in the middle of a sprint, every team member should feel authorized to interrupt that behavior. Anyone on the team should have the authority to point out when scrum is being sidestepped.

It’s critical for team members to take this responsibility for their fellow team members seriously. The power of scrum is in the dynamic it creates among a group of people. Failing to defend the scrum process is letting the other team members down.

Note: All Team Member Are Equal

Although the members of a team may report to one or more managers inside or outside of the scrum context, within a scrum team all team members are considered equals. The team members shouldn’t report to the product owner or to the scrum master because that creates a tension between the agile roles and every employee’s independent place in an organization’s hierarchy. If seniority or reporting relationships exist among employees within the scrum team, they should be ignored when it comes to following the scrum process. Anyone who notices organizational rank being used to influence the scrum process should bring the matter to the attention of the scrum master, either at the time, during a retrospective, or confidentially.

A Day in the Life

Most days, a team member will be working on code for the majority of the day, in blocks of time as long and as constant as can be arranged. A team member’s core daily duties are fairly straightforward:

developing, checking, testing, and documenting code
getting clarifications, story details, and feedback from the product owner
participating in the rituals of scrum
working with the scrum master to remove blockers for fellow team members.

The most prevalent image that springs to mind when picturing a scrum team is probably the team’s participation in a daily standup ritual, which we’ll be discussing in more detail in the chapter on scrum rituals. Every team member is expected to be available and prepared for this brief, fifteen-minute window of time. A team will usually try to schedule this so that it won’t interfere with the flow of work for the team.

Note: When to Do the Standup

For some teams, scheduling the standup right before or after lunch, or at the beginning of the work day, makes the most sense. Teams that are not co-located may need to choose a time that works for people across multiple time zones. The time can always be adjusted by the team in response to feedback gathered during sprint retrospectives.

On days when other scrum rituals are scheduled, all team members are expected to be present and participate actively. The rituals of scrum are designed to make efficient use of limited time, while producing predictable and valuable results. A good scrum master will arrange to maintain a time box around each ritual so the time commitment and the end result are predictable.

Other than participating in the rituals of scrum, all team members should be spending their days taking stories from ready to done. If the organization interferes with this work by creating excessive meetings, the team should bring this issue to the scrum master so that it can be addressed. Preserving the uninterrupted time a developer needs to concentrate on coding is one of scrum’s top priorities.

Frequently Asked Questions about Scrum Roles and Product Owner

What are the key responsibilities of a Scrum Product Owner?

The Scrum Product Owner plays a crucial role in the Scrum team. They are primarily responsible for maximizing the value of the product and the work of the Development Team. They manage the Product Backlog, ensuring that it is visible, transparent, and clear to all. They also prioritize the items in the Backlog to best achieve goals and missions. The Product Owner is the one who has the final say in what will be included in the product, making them a key decision-maker in the Scrum process.

How does a Scrum Product Owner interact with the Scrum Team?

The Scrum Product Owner works closely with the Scrum Team and the stakeholders. They communicate the vision and goals of the product to the team, and they ensure that the team is working on the most valuable features. They also accept or reject work results, and they are involved in feedback and planning sessions.

What skills should a Scrum Product Owner possess?

A Scrum Product Owner should have a deep understanding of the product and the market. They should be able to make decisions quickly and effectively, and they should be able to communicate clearly and effectively with the team and stakeholders. They should also have strong leadership skills and the ability to manage the Product Backlog effectively.

How does a Scrum Product Owner differ from a Scrum Master?

While both roles are essential in a Scrum team, they have different responsibilities. The Scrum Product Owner is responsible for the product and its value, while the Scrum Master is responsible for ensuring that the team follows Scrum practices and principles. The Scrum Master also helps to remove any obstacles that the team may face.

Can the same person be a Scrum Master and a Product Owner?

While it’s technically possible for the same person to take on both roles, it’s generally not recommended. Each role requires a significant amount of time and effort, and combining them could lead to conflicts of interest. It’s best to have separate individuals for each role to ensure that both the product and the team are given the attention they need.

What is the Product Backlog and how does the Product Owner manage it?

The Product Backlog is a list of all the features, changes, and improvements that could be made to the product. The Product Owner is responsible for managing this backlog. They prioritize the items based on their value, and they ensure that the backlog is clear and transparent to all. They also review and update the backlog regularly, taking into account feedback from the team and stakeholders.

How does a Product Owner contribute to the Sprint Review and Sprint Planning?

During the Sprint Review, the Product Owner discusses what has been done and what has not been done, and they present the Product Backlog as it stands. They also project likely target and delivery dates. During Sprint Planning, the Product Owner discusses the objective of the sprint and the items in the Product Backlog that could help achieve that objective.

What is the role of the Product Owner in the Daily Scrum?

The Product Owner may choose to participate in the Daily Scrum, but it’s not required. If they do participate, they can provide clarification on Product Backlog items and help the team understand the product goals. However, they should not use this meeting as a status check on the team.

How can a Product Owner balance the demands of different stakeholders?

Balancing the demands of different stakeholders can be challenging. The Product Owner should prioritize the needs based on the value they bring to the product. They should also communicate regularly with stakeholders to manage their expectations and to ensure that they understand the reasons behind the prioritization decisions.

What are some common challenges that a Product Owner may face?

Some common challenges that a Product Owner may face include managing stakeholder expectations, prioritizing the Product Backlog, and making tough decisions about what to include in the product. They may also face challenges in communicating effectively with the team and stakeholders. To overcome these challenges, a Product Owner should have strong communication and decision-making skills, and they should be able to manage their time effectively.