The product owner is the empowered central point of product leadership. It is one of the three collaborating roles that constitute every Scrum team (the others being the ScrumMaster and the development team).
On one hand, the product owner must understand the needs and priorities of the organizational stakeholders, the customers, and the users well enough to act as their voice. In this respect the product owner acts as a product manager, ensuring that the right solution is developed.
On the other hand, the product owner must communicate to the development team what to build and the order in which to build it. The product owner must also ensure that the criteria for accepting features are specified and the tests that verify those criteria are later run to determine whether the features are complete. The product owner doesn’t write detail-level tests but ensures that the high-level ones are written so that the team can determine when the product owner will consider the feature complete. In these respects the product owner is part business analyst and part tester.
The product owner is responsible for ensuring that good economic decisions are continuously being made at the release, sprint, and product backlog levels.
At the release level the product owner continuously makes trade-offs in scope, date, budget, and quality as a stream of economically important information arrives during product development. Trade-offs made at the beginning of a release might no longer be appropriate in the presence of new information that arrives during the release.
For example, what if several weeks into a six-month, fixed-date development effort we recognize an opportunity to increase revenue by 50% if we take one extra week (4% schedule slip) to add a newly identified feature to the release? Should we trade one week’s time and the additional cost for the extra revenue? The product owner oversees this decision. In many cases he can unilaterally make the decision. Other times the product owner might recommend a decision but still work with others to secure their input (and at times approval) to execute the decision.
Also, at the end of every sprint the product owner oversees a decision as to whether or not to fund the next sprint. If good progress is being made toward the release goal or the next sprint is otherwise economically justified, the next sprint will be funded. If poor progress is being made or the economics don’t support additional expenditures, the effort might be canceled
In addition to release-level economics, the product owner also manages sprint-level economics, ensuring that a good return on investment (ROI) is delivered from each sprint. Good product owners treat their organization’s money as if it were their own money.
Product Backlog Economics
The product owner is responsible for prioritizing the product backlog. When economic conditions change, the priorities in the product backlog will likely change as well.
Participate in Planning
The product owner is a key participant in the portfolio-, product-, release-, and sprint-planning activities.
During portfolio planning the product owner works with internal stakeholders to position the product correctly in the portfolio backlog and to determine when to start and end product development.
During product planning the product owner works with the stakeholders to envision the product.
During release planning the product owner works with the stakeholders and the team to define the content of the next release.
During sprint planning the product owner works with the development team to define a sprint goal. He also provides valuable input that enables the development team to select a set of product backlog items that the team can realistically deliver by the end of the sprint.
Groom the Product Backlog
The product owner oversees the grooming of the product backlog, which includes creating and refining, estimating, and prioritizing product backlog items
Define Acceptance Criteria and Verify That They Are Met
The product owner is responsible for defining the acceptance criteria for each product backlog item.
Collaborate with the Development Team
The product owner must closely collaborate with the development team on a frequent basis. The product owner is an engaged, committed, everyday role. Many organizations just starting to adopt Scrum fail to foster adequate product owner engagement with the development team, delaying essential feedback and substantially reducing the value of that feedback when it does occur.
Collaborate with the Stakeholders
The product owner is the single voice of the entire stakeholder community, internal and external. Internal stakeholders can include business systems owners, executive management, program management, marketing, and sales. External stakeholders can include customers, users, partners, regulatory bodies, and others. The product owner must work closely with the entire stakeholder community to gather input and synthesize a coherent vision to guide product development.
They can be grouped into four categories: domain skills, people skills, decision making, and accountability.
A Day in the Life
During weeks 1 and 2 the product owner is engaged in both portfolio planning and product planning. As part of portfolio planning, the product owner might work with the portfolio manager or the governance board to discuss portfolio expectations that could influence the new-product planning. Those discussions provide input to product planning, where the product owner, working with appropriate stakeholders and others, will perform the envisioning of the new product.
At the completion of product planning, the proposed product will be submitted to portfolio planning, where it is subjected to the organization’s economic filter to determine if development will be funded and when work can begin. Figure 9.6 shows all of this occurring immediately after product planning is complete; in many organizations there would likely be a delay between the end of envisioning and when the approval committee or governance board would review and approve funding and work would begin
In week 3 the product owner is engaged in initial release planning. This typically involves a PBI-writing (story-writing) workshop that includes internal stakeholders, the development team members, and possibly external stakeholders to generate a high-level product backlog that can be used during release planning. The development team members should be available to participate because funding has already been approved. If necessary, a surrogate team can be used if the development team is not yet formed.
Following the PBI-writing workshop, the product owner participates in an estimating workshop (probably a series of meetings over a day or two) during which development team members (or a surrogate team if the actual team has not yet been assigned) estimate the size of high-value product backlog items.
Next, the product owner facilitates an initial release-planning session (longer term planning). Because some number of product backlog items have already been estimated, the focus of this release-planning activity is on prioritizing the product backlog and balancing the constraints of scope, schedule, and budget. The stakeholders are the principal co-participants in this activity; however, some or all of the development team members will need to be involved at some point to identify technical dependencies that could affect the order of the product backlog items.
The goal is to do a sufficient amount of release planning to have an acceptable level of clarity of the overall release, and to provide initial answers to business questions such as what will be delivered and when. For most products this activity should take no more than a day or two to complete. Release planning is an ongoing activity, so we shouldn’t overinvest at this point by trying to be very precise; we’ll update the release plan as better information becomes available.
Following release planning, the Scrum team performs the first sprint (Figure 9.6 shows a two-week sprint during weeks 4 and 5). At the start of the sprint the product owner oversees the sprint-planning activity. During sprint execution, the product owner tries to attend the team’s daily scrums; this may not always be possible, but it is a good practice. During the daily scrum, the product owner listens to better understand how the current sprint is progressing and to identify opportunities to assist the development team. Perhaps a team member mentions he is a little fuzzy on the specifics of a product backlog item and needs some clarification before he can complete his current task. If it is a quick clarification, the product owner might offer it up during the daily scrum. If the answer requires anything other than a few-second response, the product owner should say, “I’d be happy to stick around after the daily scrum and discuss it with you.”
The product owner must also be available (typically every day) to answer questions and to test features as they become reviewable. If the product owner knows he can’t be available every day to perform these responsibilities, he must delegate them to an appropriate person so that the development team will not be blocked. I will discuss this idea further later in this chapter.
Also during sprint execution the product owner meets with both the internal and external stakeholders to ensure that priorities for the upcoming sprint are correct and to secure valuable user input that will affect the features chosen for future sprints. The product owner also performs frequent product backlog grooming, which includes writing new product backlog items and refining existing items, then working with the team to get them estimated, and the stakeholders and team to get them prioritized.
At the end of the sprint, the product owner participates in the two end-of-sprint inspect-and-adapt activities: the sprint review and the sprint retrospective. After these are completed, the sprint cycle repeats and the product owner participates in the next sprint-planning activity.
Who Should Be a Product Owner?
Product Owner Combined with Other Roles
If capacity permits, the same person may act as the product owner for more than one Scrum team.
Although there are times when the same individual may be the product owner and a member of the development team, it is considered a bad idea for the same person to be both the product owner and the ScrumMaster on the same Scrum team. These two roles counterbalance each other; having one person play both roles creates a conflict of interest that we should try to avoid.
Product Owner Proxy
A product owner proxy is a person enlisted by the product owner to act on his behalf in particular situations. Everyone on the Scrum team knows that the proxy is not the actual product owner, but everyone also knows that the product owner has empowered the proxy to make at least some tactical decisions on his behalf. A common example is when the product owner spends a great deal of time meeting with customers and users to make sure he has his fingers on the pulse of the marketplace. This person is reliably unavailable to the development team on a day-to-day basis. In this case, the product owner might enlist the support of a proxy to handle the day-to-day interaction with the development team regarding product backlog items. For this approach to work, it is essential that the product owner actually empower the proxy to make decisions and not unreasonably overrule those decisions in a way that would undermine the proxy’s credibility with the team.
While the product owner is focused on building the right product and the development team is focused on building the product right, the ScrumMaster is focused on helping everyone understand and embrace the Scrum values, principles, and practices. The ScrumMaster acts as a coach to both the development team and the product owner. A ScrumMaster also provides process leadership, helping the Scrum team and the rest of the organization develop their own high-performance, organization-specific Scrum approach.
Analogous to the coach of a sports team, the ScrumMaster observes how the team is using Scrum and does anything possible to help it get to the next level of performance. When problems arise that the team can and should be able to solve, the ScrumMaster’s attitude, like that of any good coach, is “I’m not here to solve your problems for you; instead, I’m here to help you solve your own problems.”
The ScrumMaster coaches a new product owner by helping him understand and perform his product owner responsibilities. Once the ScrumMaster helps the product owner get established in his role, she provides him with ongoing assistance for activities such as grooming the product backlog. Furthermore, in keeping with the sports team analogy, the ScrumMaster’s relationship with the product owner is very much like a sports team coach’s main role with the team’s owner: help the owner maximize business outcomes using Scrum, manage expectations, make sure the owner is pro- viding the team with what it needs, and listen to the owner’s complaints and requests for change and translate those into actionable improvements for the team.
The ScrumMaster is often described as a servant leader of the Scrum team. Even when acting as the team’s coach, the ScrumMaster is first and foremost a servant to the Scrum team, ensuring that its highest-priority needs are being met.
The ScrumMaster is the Scrum team’s process authority. In this capacity, the ScrumMaster is empowered to ensure that the Scrum team enacts and adheres to the Scrum values, principles, and practices along with the Scrum team’s specific approaches.
The ScrumMaster protects the development team from outside interference so that it can remain focused on delivering business value every sprint.
The ScrumMaster also takes responsibility for removing impediments that inhibit the team’s productivity (when the team members themselves cannot reasonably remove them).
A good ScrumMaster must help change minds as well. Scrum can be very disruptive to the status quo; the change that is required to be successful with Scrum can be difficult. The ScrumMaster helps others understand the need for change, the impacts of Scrum outside of the Scrum team, and the broad-reaching benefits Scrum can help achieve.
A Day in the Life
Fulfilling the Role
Who Should Be a ScrumMaster?
Some ScrumMasters were previously project managers or product managers (although product managers are more likely to transition into the role of product owner). Other ScrumMasters come from a development, testing, or other technical background.
The ScrumMaster role is not one where that level of technical excellence is exploited to its full potential. Any time technical leaders are doing ScrumMaster work, they are necessarily providing less technical leadership. Making them ScrumMasters, therefore, might adversely affect the technical outcome.
Is ScrumMaster a Full-Time Job?
Every Scrum team has a ScrumMaster, but is the ScrumMaster a full-time role? Possibly not. A Scrum team that has been working together for an extended period of time and has become highly proficient with Scrum might require less coaching than a new team made up of people who have never worked together and are new to Scrum.
ScrumMaster Combined with Other Roles
The development team’s members, collectively, have the skills required to deliver the business value requested by the product owner.
In Scrum, the development team must do all of the work to produce one or more vertical slices of working product functionality each sprint, including the design, development, integration, and testing of that functionality. Thus, we need a team that is skilled at all of those tasks.
Some organizations try to maintain a separate testing or QA team while doing Scrum. Now, I admit there are times when having a separate team that focuses specifically on testing might be necessary—for example, a regulatory requirement might be that a separate team perform a particular type of testing. However, most of the time there is no such need. Testing should be fully interwoven into the work that takes place during every sprint. Therefore, the development team doing the work during that sprint should do the testing.
Whenever you can, you should create cross-functional teams. Parceling the work out to different role-specific teams is suspect and is likely a serious impediment to the successful use of Scrum. Make sure you have a real need (besides habit) for keeping any role-specific teams.
Cross-Functionally Diverse and Sufficient
T-shaped skills mean that a team member (say, Sue) has deep skills in her preferred functional area, discipline, or specialty. For example, Sue is a great user-experience (UX) designer—that is her specialty and where she prefers to do work. Sue, however, can also work outside of her core specialty area, doing some testing and some documentation. She isn’t as good a tester or documenter as those who specialize in those areas, but she can help out with testing or documentation if that’s where the team is experiencing a bottleneck and needs to swarm people to get the job done. In this respect Sue has broad skills that allow her to work outside her core area.
Focused and Committed
Working at a Sustainable Pace
Monitor Measures and Reports
- Focus on idle work, not idle workers. To accomplish this, measure when and how often the flow of work is being impeded rather than how good you are at keeping people busy. A measure such as cycle time will expose the length of time between when work starts and when it finishes. If cycle time is increasing, you need to investigate why.
- Measure progress by working, validated assets. Does it really matter if you deliver on time and on budget if you don’t deliver a product that people want? Focus on measuring the value delivered (working and validated assets), but don’t lose sight of the variables (date, scope, budget, and quality) needed to deliver value.
- Organize flow for fast feedback. Align your measures to determine how quickly the learning cycle is completed (assume, build, feedback, inspect, and adapt).
Project Management Responsibilities on a Scrum Team
Retaining a Separate Project Manager Role