The Requirements Engineering Magazine appears quarterly. It is cost free and provides you with up-to-date articles reflecting the activities of the RE and BA community.
Simply sign up for being notified about new issues of the Requirements Engineering Magazine.
You may unregister at any time by sending a mail to firstname.lastname@example.org from the e-mail address which you have registered with.
The key to product success is to discover and deliver the right product for the right customers—and to do it at the right time. That doesn’t change when you move to an agile way of working. In fact, appropriately applying the agile mindset amplifies the imperative of eliciting and specifying the right requirements. The goal is to deliver the highest value product needs (requirements) in as short a time as possible.
In an agile or lean project, discovering these requirements is the work of agile product ownership. Product ownership intersects with the disciplines of product management, project management, and business analysis/requirements engineering. Agile and lean teams use different titles for the person in charge of this work, including product owner, product champion, or technical product manager.
Whatever the title, agile product ownership is no small task. Product owners are the champions of the product—and have ultimate accountability for the health and well being of that product. They “own” the jointly derived product vision, must deeply and emphatically understand customer needs, keep a finger on the pulse of changing stakeholder values, and continuously make decisions on what to build (or not), and when. This is true whether the product is sold commercially or is used to operate the business.
This is a tall order. Product owners cannot do this work alone. Instead, in many organizations, business analysts, requirements engineers, or testers (or some combination of them) work closely with the product owner, sometimes even taking on tactical or technical product ownership responsibilities (the day-to-day interaction with the delivery team).
Product owners—and the business analysts, requirements engineers, and testers who work with them—who handle the challenge successfully all seem to understand 9 essential practices, which are explained below.
Agile focuses on value, and delivering the highest value features as soon as possible. To do that effectively, all involved — from the c-suite to the delivery team — need to have their eyes fixed on value. One of the many responsibilities of agile product ownership, and perhaps the most important, is to share, over and over, the vision, goals, and objectives for the product. The best product owners ensure a compelling, clear and cohesive product vision emerges from collaborating cross-functional disciplines.
Great agile product owners share with their teams what they are learning from competitive intelligence, product and market research, and customer visits. When possible, they invite engineers, testers, user experience experts, and any other members of the delivery team to participate in contextual inquiry by observing actual product users interacting with the product. They may also invite the team to read customer service and complaint emails or sit in as operations or customer service personnel addresses customers’ needs. The idea is to have the team fully experience walking in the customers’ shoes.
The best product owners, or those explicitly designated as the tactical “product owners,” attend daily team standups. They don’t consider standups as status meetings, but as daily planning sessions that require facilitative leadership.
Successful product owners make themselves available every day to answer questions about work in progress. They know they are responsible for clarifying acceptance criteria and reviewing prototypes, completed stories, or other evidence of acceptance before the demo. These product owners never wait until the demo to see what the team has accomplished — otherwise they lose opportunities for real-time refinement and suffer potentially embarrassing demo-day surprises.
Great product owners always, always, always attend the team’s demos. Better yet, they facilitate the demo so that customers or proxy customers “test” the completed work. The best take it one step further and invite the world to the demo. In other words, they persuade colleagues from other product areas, technology, operations, support, and so on to attend. They also encourage their delivery teams to invite their colleagues. A standing-room only demo not only showcases the team’s work (and that of the product owner as well) but also demonstrates accountability and invites powerful feedback.
Successful product owners are part of their teams, and that includes being part of team retrospectives. They are always ready to give and receive open, honest feedback. They are integral to their teams’ — and their own — learning about the process and product. They are present and they expect retrospectives to be well facilitated, engaging, transparent, and to conclude with one or two specific actions or experiments for improvement or learning.
Some people might argue that retrospectives are only for the delivery team. I disagree. Agile product owners are part of the team — and have a right and an obligation to be there. And remember: retrospectives need to be facilitated by a skilled, neutral facilitator, who can be an agile project facilitator, a coach, or a ScrumMaster from another team.
Great product owners never relegate decisions about what features to build and when to the delivery team. They accept that this is their responsibility. They proactively encourage and expect the delivery team to share and express their opinions (hopefully backed by data). Ultimately, however, they know that the decision about what to pull from the product backlog (the living, prioritized list of product requirements) lies with the product owner.
Some product owners choose to explicitly and transparently delegate tactical decision-making to a business analyst, requirements engineer, tester, technical leader, or ScrumMaster (whomever has the right skills and product expertise) when, like many typical product owners, they are overloaded with strategic product management responsibilities. In this case, the delegate is now a tactical product owner. Typically, this is done for near-term product planning: deciding which backlog items to pull into each iteration. At the same time, the best product owners understand that once that responsibility is delegated, they cannot overrule or second guess the delegate’s decisions; otherwise, the delivery team will quickly lose faith.
Agile projects don’t attempt to understand or predict all product requirements up front. However, agile product owners still need to sketch out the long view of the product to establish a common focus and marshal organizational resources (people, money, space, governance). From that vantage point, product owners define what to build in each release, and then in each iteration. For large products, they collaborate and rely on product management to do this work.
These three levels — product (and portfolio), release, and iteration — correspond to three views (the Big-View, the Pre-View, and the Now-View) of the product.
The Big-View includes the overall understanding of what the product will be and the sequence of delivery. The Pre-View outlines what product functionality to deliver in a given release, and obtains agreement on the backlog items to deliver in the first few iterations in the release. This is articulated in the release plan. The Now-View (iteration or sprint plan) defines the items the team will deliver in an iteration, or if using Kanban, the work-in-progress.
Successful product owners are able to keep the Big-View in mind, even as they progress through the Pre-View and the Now-View.
At the Now-View, great product owners think about small, cohesive, high-value product slices. They know they need to create the product inch by inch. They realize that delivery teams need clear, measurable conditions of satisfaction so that they can create the user acceptance tests necessary to ensure that what they deliver is what the customer needs.
At the Big-View, agile product owners use a product management planning and analysis tool called the product roadmap. It is an evolving plan of product releases, with brief descriptions of their themes, features, primary customers (market segment or personas), and anticipated outcomes.
“Evolving” and “over time” are two key points that successful product owners keep in mind. As the product is developed, the roadmap must be revised to include new technologies, emerging opportunities, response to market conditions and customer feedback, team cycle time (or velocity), and new learning. If product owners were to create one roadmap at the beginning of a product’s lifecycle, freeze it, and never stray from the original path, they would miss the chance to continually discover and deliver a product that truly delights their customers.
Successfully delivering high value products depends on knowledgeable, engaged product owners. At its core, the work of agile product ownership entails one clear and essential mission: steer a team toward a vision, in small steps, with regular stops along the way to check in, learn, adjust, and move forward.