“As the chief product owner at Salesforce.com, I needed a way for my product managers to effectively connect the wants and needs of our customers and the business directly to the development teams in a highly dynamic and responsive way. Using Scrum allows us to put the product managers firmly in charge of delivering customer value. It enables them to direct the team to build the most business-critical feature first and to get them into the hands of our customers as soon as possible.”
Agile Product Management with Scrum: Creating Products that Customers Love by Roman Pichler provides a solid picture of being a product owner working in an agile context, which is definitely a collaborative affair! Early on, Pichler builds the case for teamwork, with teams being close to the customer:
“To create a winning product, the product owner, ScrumMaster, and team must develop an intimate understanding of customer and user needs, and how these needs can best be met. The best way to do this is to involve customers and users early and continuously in the development process.”
Pichler follows this up by quoting Ed Catmull, president of Pixar, who says, “If you give a mediocre idea to a great team, they will either fix it or throw it away and come up with something that works. The wisdom of many is preferable to the brilliance of one.”
Pichler distinguishes a customer and a user, clarifying that meeting the needs of both are essential: the customer is the person purchasing the product and the user is individual actually using the product. As an example, Pichler states that, “The needs of its users might include ease of use and high productivity. The company purchasing the product, on the other hand, might be concerned about the total cost of ownership and data security.”
Pichler also clearly differentiates between customer needs and product attributes. “Selecting the relevant customer needs tells us which market or market segment we are going to address. By focusing on the needs, we view the product as a means to an end—serving the customer or user. Product attributes, on the other hand, are the critical properties the product must have in order to meet these needs. A touch screen, for instance, is a product attribute. The underlying need for that attribute is likely to be ease of use.”
Being true to Agile, Pichler states that, “Once we have identified the product attributes, it’s often useful to prioritize them; attributes serving several needs are important and should be high priority.” (As we all know, everything can’t be a priority!)
Ultimately, all of this comes back to the team, a team connected to the customers and users: “To create a winning product, the product owner, ScrumMaster, and team must develop an intimate understanding of customer and user needs, and how these needs can best be met. The best way to do this is to involve customers and users early and continuously in the development process.”
The product backlog directs where an Agile team is going. Pichler provides the following observations and advice on product backlogs:
- The product backlog is beautifully simple—a prioritized list of the outstanding work necessary to bring the product to life.
- The product backlog supersedes traditional requirements artifacts, such as market and product requirements specifications.
- The product backlog has four qualities: It is detailed appropriately, estimated, emergent, and prioritized, making it DEEP.
- Grooming the product backlog collaboratively is fun and effective. It creates a dialogue within the Scrum team and between the team and the stakeholders. It removes the divide between “the business” and “the techies” and eliminates wasteful handoffs.
- What makes a product backlog item valuable? My answer is simple. An item is valuable if it is necessary for bringing the product to life.
- Before including an item in the release, decide if the product could still achieve the desired benefits without that item. This helps create a simple product, a product that implements the minimum functionality.
- Don’t just scrutinize new requirements. Reexamine existing ones as well. Superior alternatives often arise after the Scrum team has learned more about customer needs and the solution being developed. Simplify, prune, and strive for order—like a gardener pulling out the weeds and trimming the shrubs.
- A product backlog that is too detailed and too comprehensive does not support the emergence of requirements. It does not view requirements as fluid and transient but rather as fixed and definite; it freezes all decisions about how customer needs can be satisfied at an early point in time.
- A product backlog that resembles a child’s wish list for Santa contains anything and everything we have thought of that we might ever need.
- A wish list for a backlog is not only notoriously difficult to prioritize; it also limits the product’s ability to evolve based on customer and user feedback, as too much functionality has already been identified.
Pichler tackles the subject of release planning in an Agile context, noting that, “Release planning starts with making a decision about which project lever—time, cost, or functionality—cannot be compromised to launch a successful product. Is adherence to the launch date mandatory? Is the development budget fixed? Or do all product requirements in the product backlog have to be delivered? Fixing time, budget, and functionality is not possible; at least one of the three levers has to act as a release valve.”
While Pichler states that time, budget and functionality are one of the levers that cannot be compromised, he does weigh in on functionality: “Fixing functionality is a bad idea. Even with a product vision in place, the product’s exact properties, its functionality and features, are not all known up front but are instead discovered based on customer and user feedback.”
Pichler definitely prefers flexibility in shaping product features and is all too familiar with the headaches with matching functionality and dates, as the following comment states: “…choosing a launch date based on the work in the product backlog is difficult, as it forces the team to freeze requirements and often results in a poor estimate.”
As you might expect by this point, Pichler points out that, “Release planning takes place throughout the project, as the team listens and responds to customer and user feedback. Shifting from document-driven planning and reporting to conversation and dialogue allows the Scrum team to use simple planning techniques, which makes planning itself simpler and more transparent.”
Pichler not only likes flexibility, he clearly strives for a realistic approach that enables innovation, leveraging Agile’s sustainable pace and setting expectations that are all too often incorrect with the word “commitment.”
“There is little benefit in trying to achieve an overly ambitious goal in one sprint only to be exhausted in the next one. Scrum favors a smooth, steady flow of work from the product backlog into the sprints. Reliability is more valuable than false ambition; it is the prerequisite for making realistic forecasts. And too much pressure kills playfulness and hampers creativity.
“Be aware that a commitment is not a guarantee. It can take a new team two to three sprints to learn how to make commitments it can meet. Plus, software development is full of unknowns; uncertainty and risk go hand in hand with innovation.”
I’ve scratched the surface in this review, but the book provides an excellent overview of Agile Product Management with Scrum that is a must read for anyone involved with product management with Agile teams. I certainly found it consistent with everything that I understand and have experienced with Agile development.