Enterprises often have lots of time-sensitive opportunities and insufficient skilled or creative people (called “developers” in this pattern) to do everything.
Problem: Stakeholder competition distracts creative people, interferes with profitable work and creates office politics …
Context: No one is controlling creativity. No one steps up to stop a doomed creative effort. Competing stakeholders must lobby developers to get work done, disrupting productivity with ad hoc meetings.
Forces
Many stakeholders want to get value from developers, each with legitimate needs that compete for developer time. These can include product managers, customers, users, marketing, sales, support, operations, lawyers, shipping, finance, designers, testers, architects, etc. Different stakeholders create conflict.
Individual developers like to pursue their own passions. But their personal priorities may not produce a successful outcome, since few developers study their market (synthesis requires one perspective, analysis another). By working independently from other developers, they extend the overall time of the most profitable venture (and so, without direction they should really jointly decide on a single team activity). The organization could run out of money or time, causing developers to lose their jobs.
Stakeholders can pressure team members, arranging meetings that disrupt productivity. A stakeholder could expend many person-hours educating team members on why that stakeholder’s priorities are more important. Then the stakeholder with the greatest skill in lobbying may win, to the detriment of the organization.
The most productive developers can damn their own productivity. Stakeholders could complain that these developers aren’t listening to their needs, motivating higher-level individuals to arbitrate to achieve a compatible consensus. This takes productive time away from both non-developers and developers. Resentments might persist. Developers might try to hide from stakeholders, just to get some work done.
When team members share responsibility for prioritizing work, they can become indecisive. When a product fails, each team member can plausibly blame another. A team member offering clear requirements can attract significant personal risk; they could cause the product to be terminated early if the product can’t be profitably built (a good thing) and become a scapegoat (a bad thing, because the best are blamed). Conversely, a member who proposes excessive preliminary analysis or unclear requirements can hide from blame in most circumstances. There’s danger in helping, safety in dithering.
Solution: … therefore, appoint a single person to gather and rank order requirements for a development team.
This single person is called the Product Owner. The Product Owner creates a well-ordered Backlog of Backlog Items, explains it to the development team, and forecasts delivery times based on analyzing developer productivity data.
The Product Owner articulates proposed development effort in Backlog Items. Each Backlog Item provide sufficient detail (conveyed in writing or conversation) that developers can estimate relative effort compared to other Backlog Items. Near-term Backlog Items should be sufficiently small that they can be feasibly completed by the team in a release cycle [Sprint]. If longer, the Product Owner should attempt to break down these near-term Backlog Items. To better motivate and direct the outcome, the Product Owner can articulate the economic gains sought by the Backlog Item as a Four Part User Story.
The Product Owner strictly ranks Backlog Items in a desired completion order, creating a Backlog. The Product Owner must rank dependencies before dependents. Interdependent Backlog Items create inflexibility. Product Owners who want to more rapidly adapt to team and market discoveries will craft Backlog Items with fewer interdependencies.
Respecting dependencies, the Product Owner should rank the Backlog Items roughly by decreasing ROI (return on investment) or decreasing Cost of Delay. ROI is the relative comprehensive corporate value of Backlog Items divided by the relative cost (estimates provided by the team, other costs). By ranking requirements by gain and dependency, the Product Owner can get the most valuable work earlier (which can help pay for less valuable work done later).
A well-estimated Backlog can communicate desired functionality over a long time period [Forecast Horizon]. However, people cannot effectively compare more than about 7±2 Backlog Items [Chunk Before Choosing], so a Backlog should not have too many items. Product Owners seeking to limit cognitive load (a good idea) will craft Backlogs with no more than 9 near-term Backlog Items that can be easily completed, then geometrically increase (roughly) the size of Backlog Items to ultimately compose the expected development lifetime. If we complete Backlog Items in 1-week release cycles, and we double Backlog Item sizes roughly each week, we can represent a full year of work in 42 Backlog Items.
Agile projects often attempt to implement the new, the untried, and the nearly impossible—this is not the problem domain in which controlling tasks to achieve a fixed plan will succeed. This is a problem domain that demands the innovative exploration of possibilities. —Jim Highsmith, Cutter Journal (17 Jan 2007)
A geometric Backlog can be a valuable tool for inspiring short, medium and long term design thinking (software architecture, etc.), and ordering major related efforts. The relative accuracy in composing and estimating should not change: a Product Owner should invest about the same time composing a gigantic Backlog Item as a small one, a team should invest about the same time estimating a gigantic Backlog Item as a small one. Of course, when near-term Backlog Items are completed, chunky items rise to the top; these and the items below must then be broken down to keep a “fractal picture of the future”.
Development efforts typically evolve with time. Early in a project, Backlog Items may focus on generating market knowledge [Lean Startup] or exploring usability [Usability Testing]. These high-ranked items reflect the importance of building something that generates economic value. Later in a project, a Product Owner should shape Backlog Items to reflect market and production discoveries that emerged earlier. By using a geometric Backlog, the Product Owner avoids creating detailed long-term plans too early in the process [Limit Work-in-Process].
The Product Owner should seek to improve their understanding of Backlog Item value. Stakeholders commonly insist that all their requirements are exceedingly important, but deeper digging can establish reachable goals and comparative value. Customer Development [Lean Startup] provides an agile process to measure value more accurately than stakeholder opinion.
The Product Owner role serves as a value oracle for development teams. The Product Owner role is not a comprehensive job title. A person with the Product Owner role may also perform traditional Product Manager activities: analyzing business, pricing, sales and distribution models; developing marketing collateral; negotiating contracts; designing, measuring and learning from market experiments; coordinating user experience research; making brand decisions, etc. In very small efforts, the CEO or boss may take the Product Owner role (danger: estimation bias, data quality issues and resentment may arise under overbearing bosses). In large, complicated efforts, a person might perform only Product Owner duties, representing the interests of a product management team to a development team.
The Product Owner is accountable for the value production of the team. Responsible Product Owners can reasonably forecast release dates of important features (with dates and probabilities, ideally) using team data, can explain the purpose and external behavior of requested features.
Examples
Different agile methodologies give this person different names. In Scrum, a single Product Owner orders a Product Backlog, and through that ordering communicates priorities to a Development Team. In XP (Extreme Programming), a single Onsite Customer orders Features. These functions are the same, Scrum terminology is far more commonplace, and so we use the term Product Owner.
Resulting Context
Stakeholders lobby only one person, the Product Owner, to get developer team assistance on a Backlog Item. Stakeholders have no other means of getting developer effort, so they don’t waste time meeting with developers. Product Owners can provide a rough forecast of completion by looking at the Backlog Item’s position in the Backlog and examining the development team’s historic production rate. If the forecast time is not sufficient, a stakeholder can either withdraw the Backlog Item or lobby a higher-ranked person to influence the Product Owner.
With the Product Owner accountable for the team’s value production, the Product Owner will prefer to limit work-in-process to get the most profitable work done faster (thus helping pay for later, less profitable work). The team will not be burdened with much work-in-process.
Known Uses
Ubiquitous in production agile software methodologies, and in industrial practice.
Aliases
- Onsite Customer (Extreme Programming)
- Product Manager (corporate vernacular, includes other functions)
- Boss [Strategy Scrum Teams]
Related Patterns
- Backlog
- Backlog Item
- Chunk Before Choosing
Contributors
Primary author: Dan Greening
