How Scrum Generates Increased Productivity, Part Two: The Product Owner By Laszlo Szalvay This article originally appeared on Agile Journal on Monday, May 11, 2009. To access it online, visit: http://www.agilejournal.com/ articles/columns/articles/163 5-how-scrum-generatesincreased-productivity As discussed in part one of this series, the Scrum framework is designed to be a lightweight management wrapper-a minimal set of practices that complement and hopefully improve an organization's existing business practices, processes and culture. However, because the Scrum framework is composed of relatively few roles, meetings, and artifacts, none of them are redundant or expendable. For organizations to unlock Scrum's potential-such as its ability to boost productivity, mitigate risk, and accelerate product development cycle time-the framework must be faithfully preserved, mastered, and tweaked only through retrospective meetings. The easiest way to ensure all aspects of the framework are observed is through a strong understanding of how they enable Scrum's benefits. Once it is clear how various parts of the framework interact to facilitate productivity, Scrum teams-as well as managers and stakeholders-will want to protect the basic framework to make sure that its potential is maximized. As stated in part one, I'll illustrate how each of Scrum's roles works to facilitate productivity on an individual basis as well as in concert with other roles. As mentioned previously, when all three roles work in tandem, the overall effect is much greater than the sum of its parts. In part two, I'll discuss the most demanding of the Scrum roles: the Product Owner. The Product Owner In Scrum, the Product Owner is the one person responsible for the project's vision and direction. He or she leads by communicating with the team, outlining chunks of work through the composition of product backlog items (PBIs), and then prioritizing those PBIs. Of course, there is some negotiation involved in this process. He or she usually consults outside of the team with stakeholders (other Product Owners, business analysts, business owners, end customers, etc.), to make sure their interests are reflected in the backlog. Then he or she must parlay the PBIs to the team, to make sure the acceptance criteria of the PBIs are clearly understood. For this reason, the Product Owner must remain available to answer the development team's questions and provide updates to stakeholders.
Why Is Product Ownership So Demanding? The stresses associated with Product Ownership, however, should not be swept under the carpet. The primary reason this role is so difficult can be traced back to why projects fail or are challenged in the first place. According to the Standish Group's report "Chaos," the most common reasons a software project failed or was impeded are: 1. Lack of User Input (12.8%) 2. Incomplete Requirements and Specifications (12.3%) 3. Changing Requirements and Specifications (11.8%) 4. Lack of Executive Support (7.5%) 5. Technology Incompetence (7.0%) 6. Lack of Resources (6.4%) 7. Unrealistic Expectations (5.9%) 8. Unclear Objectives (5.3%) 9. Unrealistic Time Frames (4.3%) 10. New Technology (3.7%) Other (23.0%) Realistically, out of those top 10 reasons, all but "technology incompetence" and "lack of resources" likely fall squarely on the shoulders of the Product Owner. That is, eight of the top 10 reasons relate to poorly articulated vision or a poor understanding of what the team can reasonably accomplish. Certainly, there is pressure on the team to deliver a product increment and the ScrumMaster to ensure processes run smoothly, but, without doubt, the report makes it clear that strong leadership and vision are most critical for software project success. Thus, the Product Owner's job is actually much more demanding than "owning the backlog" would imply. Still, while strong leadership is a requisite of a successful Product Owner, Scrum asks that he or she give the team adequate room for leadership within the team to naturally emerge. As such, one commonly observed anti-pattern in Scrum is the tendency of the Product Owner to micromanage teams. The role's combination of authority and mandated accessibility to the team presents most Product Owners, especially those with backgrounds in traditional project management, with a temptation to become overly involved and direct at the task level. However, one of Scrum's most defining facets (and one that's central to increasing productivity) is its charge for teams to selforganize. As a result, determining what backlog items a team will work on each sprint is not left to the sole discretion of the Product Owner, but, rather, arrived upon through a negotiation at the sprint planning meeting. In this process, the Product Owner determines which product
backlog items (PBIs) the team will tackle, but how those items are completed-i.e. how the team decomposes them into tasks-is the team's decision. In short, tasks are defined and used by the team. When Product Owners engage in task-level management, it can lead to a perversion of Scrum's fundamental principles and result in dysfunction associated with traditional project management such as: (a) "Employee resource balancing"; (b) Product Owners assigning tasks based on perceived skill sets; or (c) Product Owners trying to match reality to an ideal' sprint burndown chart. Because Scrum values team self-organization, it asks the Product Owner to respect the team's ability to determine for itself how to complete sprint goals as they relate to task management and, otherwise, stay out! For an advanced discussion of macro-measurement, Michael James has written a great whitepaper that is freely available (http://danube.com/whitepaper/macro-measurements) and Kane Mar's article on what your sprint burndown chart tells you about your team in this article which appeared on the Scrum Alliance website (http://www.scrumalliance.org/articles/7-whats-your-sign). The Product Owner and the Team The Product Owner's relationship to the development team allows both parties to maximize their productivity. Because planning activities occur at the beginning of the sprint, the team receives its negotiated sprint goals from the Product Owner and then has the entirety of the sprint to complete the work. And while the Product Owner must remain available to the team to answer questions, they are, ultimately, on their own to determine task-level management or the how' in how will we get this work done (hence, self-organization). With the team storming to complete its goals, the Product Owner is then freed to perform other forward-looking activities, such as meeting with stakeholders, interviewing and surveying customers, release planning, backlog grooming and metrics analysis. In essence, the team's mandate to self-organize allows the Product Owner to step back from the granular perspective of each sprint's progress to consider big picture strategy, while still remaining "on-call" to answer the team's questions regarding ambiguity that may not have been cleared up during the sprint planning meeting. Although backlog grooming-which is also referred to as backlog
maintenance-is not a formal component of the framework, Scrum founder Ken Schwaber recommends teams dedicate five percent of every sprint to this activity (for example, a team using four-week sprints would spend one day grooming its backlog per sprint). During this meeting, the team, the Product Owner, and the ScrumMaster come together to prepare the backlog for the next sprint planning meeting. These activities typically include adding new stories and discussing new epics, or features, extracting stories from existing epics, and estimating PBI effort. In other words, backlog grooming represents an opportunity to streamline sprint planning meetings-thereby ensuring they do not stretch on for hours or days. When product backlog items contain clearly defined acceptance criteria and are estimated by the appropriate team members, the team can avoid planning meetings that are tense and overly long. For a great way to estimate PBI effort, I would recommend Kane Mar's "spiciness" model, described here: http://kanemar.com/2006/01/28/story-points-as-spicy-ness-usingrsp-to-estimate-story-points/. One thing to be wary of is sprint raiding,' in which the Product Owner continues to assign work to the team mid-sprint. Although the Product Owner can answer questions and help the team better understand boundaries surrounding the acceptance criteria of PBIs, he or she cannot assign additional PBIs to the team during the sprint, unless the team has burned through all of its PBIs. If you find that this is happening on your team, I would suggest shortening the length of your sprints or encouraging the ScrumMaster to have a heart-to-heart conversation with the Product Owner as to how this can contribute to failure and chaos. (However, this scenario could also be indicative of weak acceptance criteria on your PBIs. ) If the Product Owner feels the need to suddenly make changes to the sprint-in-progress, the Product Owner needs to cancel the sprint and begin again with a new sprint planning meeting with the team. This can contribute to an even more chaotic and distracting work environment, so it should be considered a last resort. Furthermore, the Product Owner must prioritize the backlog based on the items that will yield the most business value in the next sprint. According to Michael James, "In Scrum, the Product Owner prioritizes requirements, generally according to anticipated Return on Investment (ROI)." Dan Rawsthorne, PhD and others have worked to advance the
dialogue on agile metrics, addressing topics such as Earned Business Value (EBV) on a Scrum project. EVB, Velocity (the number of estimation points that a team can complete in an average sprint), backlog grooming, and, of course, Mike Cohn's Enhanced Burndown Chart are all tools that can help the Product Owner with his or her decision making, but, ultimately, that decision cannot be outsourced. That could mean making tough or unpopular decisions during sprint planning. Sometimes, the team might not be thrilled with the Product Owner's decisions, but, in the end, even when the entire team fails, it's the Product Owner who must face the music. As such, he or she must aggressively re-factor which features of a product are most critical throughout the cycle (by speaking with stakeholders, interviewing and surveying end customers). Just as the development team commits to producing the negotiated work for the Product Owner, the Product Owner must deliver the product to the customer. For an advanced discussion of EVB, agile metrics, and a demonstration of one way to implement them, I would again refer readers to Dan Rawsthorne's article in the Agile Journal: http://www.agilejournal.com/articles/columns/articles/54-calculatingearned-business-value-for-an-agile-project. The Product Owner and the ScrumMaster Just as the ScrumMaster works to resolve impediments and, consequently, facilitate productivity for the team, he or she plays a similarly supportive role for the Product Owner. Much of that support can be summarized as ensuring that the Product Owner has all the information he or she needs to make informed decisions-including status updates, impediment updates (both organizational and teambased), technical implications, and organizational impact. However, the ScrumMaster also needs to make sure that accurate information is moving from the Product Owner to the team, so that it can maintain productivity and hit its sprint goals. For example, a ScrumMaster might ask a Product Owner to clarify prioritization decisions. However, since Product Owners often insist they want all the features because they're equally important, a ScrumMaster can skirt this challenge by phrasing questions in a way that force the Product Owner to prioritize the work with a greater degree of precision. For instance, a ScrumMaster might ask, "Which feature would you like completed first?" or "Which feature will generate the most Business Value?" Especially in the early stages of a Scrum transformation, it's not a given
that a team will end up with a Product Owner who is a natural fit for the role-or even someone who has ever written formal requirements. If this is your case, one way the ScrumMaster can work with the Product Owner to articulate the vision for the product is by asking leading questions through informal conversation. Questions such as "Why are we building this?" and "Why is feature X more important than feature Y?" will force a Product Owner to articulate business needs and explain the logic behind prioritization. Of course, when requirements are clearly defined and prioritized, all that's left for the team to do is get to work. Common Impediments to Successful Product Ownership Given the degree of responsibility this role faces, it is recommended individuals volunteer to serve as Product Owner. Quite simply, if a Product Owner cannot give a team his or her full attention, especially during the transformation period, it dramatically reduces the project's likelihood of success. Related anti-patterns that are commonly observed during the transformation process include: (a) Product Owner by proxy. When an organization first implements Scrum, it is extremely common for team members to lack an understanding of how the Scrum framework facilitates efficiency. As such, a Product Owner might perform his or her role by proxy. However, because the Product Owner is the single individual responsible for the success of the project, "outsourcing" such responsibility can be disastrous. Quite simply, this is interrupts Scrum's attention to communication and transparency by introducing another channel of communication-who likely has less of an understanding of what the customer wants than the true Product Owner. (b) Part-time Product Owners. The team depends upon the Product Owner to clarify requirements and provide direction. When a Product Owner is only available to provide input part of the time, the team is, likewise, only productive part of the time. (c) Off-site Product Owners. While an offsite Product Owner might fully committed to the team (unlike the above example), there is no substitution for face-to-face communication. When a Product Owner attempts to perform his or her duties remotely, the chance of a communication breakdown increases significantly. (d) Product Owner/Team members. Another common anti-pattern is actually a variation of the part-time Product Owner. When a Product Owner is also a team member, he or she effectively splits their time between considerably different job functions. When this occurs, the team's performance tends to worsen. Not only does the team suffer from the fact that it includes a distracted member, but the overall
health of the project suffers from a negligent Product Owner. Conclusion As the single responsible party for the vision of a project, the Product Owner is the Scrum framework's most demanding role. But because Scrum distributes authority and responsibility among the three primary roles, the Product Owner is supported through the team's selforganization and the ScrumMaster's efforts to ensure that all parties are connected and informed. As the team self-organizes around task management, the Product Owner can focus on big picture strategies, or macro-measurement, while remaining on-call to answer the team's questions. The ScrumMaster's role as a liaison between the Product Owner and the team helps ensure that requirements are actionably articulated while impediments are clearly visible. When all of these activities converge, the result is a team organized around a clear project roadmap that's ready to move forward. About the Author In August 2000, Laszlo Szalvay founded Danube Technologies, Inc. with his brother Victor in Seattle, Wash. to provide software and training exclusively focused on the Scrum method of agile software development. The company's ScrumWorks Pro and ScrumWorks Basic products are licensed to more than 105,000 software professionals worldwide, making it the most widely used software in the industry for managing Scrum projects. ScrumWorks Pro recently received a Jolt Productivity Award at the 19th annual Jolt Product Excellence Awards. Danube complements its software offering with a comprehensive schedule of ScrumCORE TM training courses, which are taught globally by Danube's five Certified Scrum Trainers. The company's on-site software delivery model makes it the leading choice for enterprises of all types, including large corporate and government organizations, which require the utmost in security, compliance, ease-of-use and customization. Danube's customers include Adobe, Amazon.com, AMD, F5, General Electric, HP, Intel, Intuit, Kofax, LexisNexis, Microsoft, Motorola, Oracle, QVC, Siemens and Sun Microsystems. Danube is self-funded and has achieved steady organic growth as Scrum has emerged as the preferred agile method for developers and executives. The company is headquartered in Bellevue, Wash. and has a sales office in Portland, Ore. Please visit
http://www.danube.com or call (503) 248-0800 for more information on Danube.