Introduction
The Product Owner role is highly strategic as she/he sets the direction fo the product that the development team will build. Often times this role is confused as someone that just writes detailed requirements and pass those to the team.
In other cases the Product Owner role is confused with the Project Manager role that makes sure that things work according to a planed scheduled, ironically meeting the schedule doesn’t guarantee that the product will perform well in the market or even solve a problem for the end users.
In the early days of eXtreme Programming a need was perceived for having in a team someone(s) with business domain knowledge and that can voice the needs from the stakeholders [Beck99]. Scrum put more emphasis on that need and introduced the Product Owner role and made explicit that the she/he has final saying on the product.
It’s common to hear that the Product Owner’s primary tool is the Producto Backlog; that is factual but simplified to an extreme because there are other tools and knowledge from other disciplines that the Product Owner should master in order to do her/his job. The job of the Scrum Master is having that type of knowledge and guide the Product Owner’s learning via coaching and mentoring.
Steps for Discovering the Product and the Product Backlog
Before even thinking in creating a Product Backlog there are several steps that often are ignored and because of that teams might end up building the wrong product, building it too costly or building it too late.
The first step is to understand the system in which the product will exit, this means not only thinking narrowly in the product but thinking systemically. It’s vital to understand that is not about saying yes to all client’s request but systemically analyzing all the variables that will influence product decisions [Larman17].
The second step after understanding the system consists in identifying what is the problem that the product aims to solve. From a Lean perspective the product doesn’t really solves a problem, instead will mitigate it and by evolving the product better mitigations will be discovered.
The third step is evaluating with the development team the product technical feasibility; feasibility analysis can also be extended to other areas like finance, legal, marketing and others. A common trap that many teams fell in is to invest too much time analyzing and discussing feasibility instead of start building the product in little increments; it’s worth to remember that Scrum says start earlier and validate the product hypothesis as soon as possible.
The fourth step is discovering what features the product will include, who will be the users, and how they’ll benefit from using those features [Watts17]. The techniques from Innovation Games described by Hohmann [Hohmann07] have proveen to be very valuable for discovering and understanding a product. An important recommendation is to use those techniques in a face-to-face workshop with stakeholders, the Product Owners, representatives from the Development Team and the Scrum Master as a facilitator.
The fifth step consist in putting all product details in a Product Canvas [Pichler10] in which is very useful to include paper prototypes of how the product will look.
The sixth step is to discover the PBIs that will form the backlog and order them. User Story Mapping [Patton14] is my favorite technique for doing the discovery part.
The seventh and sometimes controversial step is to estimate PBIs in the Product Backlog. This is controversial because estimates often times can be interpreted as hard commitments. In actuality estimates are just that estimates that will need to be reestimate as we learn more about the product. Further, and estimate is a placeholder that remembers us that we need to keep talking and refining our understanding about a PBI.
The eight and last step is to define the product strategy [Pichler16], that has a very important component that is the Release Plan that defines how frequently the team intends to ship releases out of the door. The Release Plan must also include other important events that need to happen in alignment with the development of the product, event like a marketing campaign milestones, provisioning IT infrastructure, legal contracts, etc.
Lastly, whichever product that has been discover, alongside its backlog and Release Plan, will change in order to accommodate to market conditions and other forces. This is completely expected and should be embraced as the whole point in being Agile is adapting the product as we build it.
Thinking in the Backlog as a List
One of the recurring themes that I’ve observed in many organizations is the over complexation of the product backlog concept. Agile Lifecycle Management electronic tools add additional terminology, interface and options that one needs to learn before even attempting to create a backlog.
Some Project Managers also contributed to the confusion thinking in the backlog like a new unidimensional version of a tradición Gantt chart where they can still apply technique that they know.
Richardson [Richardson05] bring some light by pragmatically presenting the backlog in an analogous way and connecting it to a grocery shopping list.
Following that train of thought a grocery shopping list has characteristics such as:
- Publicly visible and available meaning that there is no secret Product Owner’s list, instead there is a list that everybody in the Development Team has access for editing but only the Product Owner can change the order of the items
- Prioritized using several criterion besides only estimates for duration
- In a timeline that implies that the items in the list can be completed in weeks or months but definitely not years. If the team runs out of time items in the bottom of the list might be sacrificed
- Active and not static that means that the list will change over time to reflect the most current learnings of the Development Team, the Product Owner and the stakeholders
- Measurable in a way the some qualifier can be applied to determine when an item is completed or not
- With a clear purpose that assure that if we’re implementing those items is because they’ll be part of a product that will be shipped, not just implementing items that may end up archived
Tools for Keeping the Product Backlog
Nowadays in the market you can find several electronic tools ranging from the ones that present a simple online task board to the ones that are part of a larger ecosystem with traceability across multiple tools.
A common feature in the majority of this tools is that they seem to be oriented to generate reports for upper management with metrics and indicators, and tracing back the work to who in the team is doing (or suppose to do) what.
Another characteristic of these tools is that they don’t allow a great degree of experimentation because they were designed as out of the box solutions that include terminology and standardized processes. Going back to Toyota roots is good to remember that we want tools that allow experimentation and continuos improvement in the tools themselves and in how the teams uses them.
Taking the above into account, a very simple alternative is to use Google Spreadsheets for keeping the backlog and a wiki for capturing additional details about PBIs. Even if this idea seems too amateurish it respects the principle of simplicity, saves costs, promotes experimentation, reduces the learning course and facilitates communication.
It is not just my personal experience observing good results with the tools described above but also authors like Larman and Vodde [Larman10] have observed the same at a much larger scale.
Including the Product Owners in the Team
Ideally Product Owner should be a full time member of the team but things like outsourcing and offshoring have distorted that.
If the Product Owner works for an organization that hires another organization abroad is highly recommended that she/he travels at least once a month to work and spend time with the remote team(s).
Having physically present the Product Owner is very valuable especially in the Sprint Review, the Sprint Retrospective and the Sprint Planning that will come the day after.
If the Product Owner participates in the Sprint Retrospectives she/he will be able to hear first hand about the problems and inefficiencies that the team suffered during the Sprint and also contributing her/his point of view.
Similarly by being present the Product Owner will be able to learn in all sincerity how her/his work is perceived and think in what corrections she/he might need to do to better interact with the team.
Another benefit of having the Product Owner in the room is hearing from someone that is more connected to the business, and that can provide a different perspective about what to improve.
Conclusions
Product Owners have the potential to reshape the industry with new and innovative products but that is unlikely to happen if Product Owners lack an Agile mindset along side with an entrepreneurial spirit and solid knowledge about their business domains and the techniques and tools of their craft.
Practical experience is esencial and I consider that for a Product Owner having the opportunity to work in several products, one at a time, in a time horizon of let’s say five years is more enlightening that just writing user stories for the same product during the same period of time.
Finally it’s worth emphasizing a fundamental concept: the Product Owner role and in fact the idea behind having a Scrum Team is having a highly effective and motivated team that builds a product that can have a positive impact in the market.
Bibliography
Beck99 Beck K., 1999. Extreme Programming Explained: Embrace Change, Addison-Wesley
Larman17 Larman C., Vodde B., 2017. Large-Scale Scrum More with LeSS, Addison-Wesley
Watts17 Watts G., 2017. Product Mastery: From Good to Great Product Ownership, Inspect & Adapt Ltd
Hohman07 Hohman L., 2007. Innovation Games: Creating Breakthrough Products Through Collaborative Play, Addison-Wesley Professional
Pichler10 Pichler R., 2010. Agile Product Management with Scrum: Creating Products that Customers Love, Addison-Wesley Professional
Patton14 Patton J., 2014. User Story Mapping: Discover the Whole Story, Build the Right Product, O’Reilly Media
Pichler16 Pichler R., 2016. Strategize: Product Strategy and Product Roadmap Practices for the Digital Age, Pichler Consulting
Richardson05 Richardson J., Gwaltney W., 2005. Ship it!: A Practical Guide to Successful Software Projects, Pragmatic Bookshelf
Larman10 Larman C., Vodde B., 2010. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum, Addison-Wesley Professional
