Skip to main content

Author: Ellen Gottesdiener

It’s Time to Put Value in the Driver’s Seat

Deliver value. It is the mantra of every agile or lean team and a big part of the conversation among traditional or waterfall teams as well. You would expect, then, for all teams to define a product’s value explicitly and transparently—to make it the basis for every decision, the determining factor behind every potential product feature. Yet, too often this is not the case.

Let’s explore how successful teams define value, use it to drive decisions, and consider and reconsider value throughout a product’s lifecycle.

Let Value Be Your Guide

According the Value Standard and Body of Knowledge value is “a fair return or equivalent in goods, services, or money for something exchanged.” In other words, value is what you get for what you give up.

What one company considers valuable, at a certain time, might be completely different than what matters to another company, or to the same organization at another point in time. For example, one team we recently worked with selected a minimum set of product features, or slice of functionality, that could be delivered to their primary end users within two months, so as to stay within the bounds of a highly profitable purchase agreement. Another organization identified the set of features that simultaneously reduced operating costs and flagged conditions in the field that could risk life and limb.

So how did these teams decide on what to deliver? What enabled them to quickly, transparently, and collaboratively select the highest value features? They relied on value to steer their product in the right direction.

Choose Your Destination

Defining a product’s desired result, before building it, is fundamental to that product’s success. As the old saying goes, if you don’t know where you’re going, any road will take you there. Successful agile teams start by determining where they want to finish.

In our first article in this series, we described how product stakeholders from the customer, business, and technology realms become collaborating partners. These product partners envision the product, define goals, and specify measurable objectives, creating a high-level view of the desired product outcomes. These key markers describe and quantify the product’s anticipated value, ensuring that the team is always moving in the correct direction.

One aspect to consider is the tangible, financial qualities, including measures such as IRR (internal rate of return), ROI (return on investment), TCO (total cost of ownership), and EVA (economic value added). Value, though, is about more than money; it is also about intangible aspects, such as user experience, joy, belonging, convenience, sense of well being, trust, alignment to strategy, upsell potential, or brand projection. These intangibles can often be as or more important than tangible value qualities, such as cost or profit margins. Though these intangible considerations are more elusive to measure, they can be quantified by accounting for uncertainty and risk. (For more on this, we recommend Hubbard’s How to Measure Anything).

One of the ways to uncover both tangible and intangible value is to have the product partners explore and share their own value considerations. A value consideration is some variable that is used when assessing the value of your product options. For example, the customer partners might include safety or a convenient-to-use product among their value considerations. Business partners (the people sponsoring the product’s development) might be most concerned about market positioning or protecting the company’s reputation. The technology partners (those who build the product) might be more interested in feasibility and compatibility with existing and future architecture. Making all of these varied (and often competing) value considerations transparent is crucial for making good decisions.

Identify Potential Hazards

Another aspect to consider when making value decisions is risk. Like value, risks change with time and can impede, mitigate, or even obviate delivered value. These risks include rework (if the wrong thing is delivered or technical debt is incurred), noncompliance, opportunity cost, and more. We recommend you consider risks along the same categories as we consider product partners: customer, business and technology.

Dependencies—product and project, internal and external—also constrain product decisions. For example, the partners need to understand the consequences of deviating from an optimal sequence, in both time and cost.

Plot the Preliminary Route

With the guideposts of vision, goals, and objectives in sight, and a clear view of all the tangible and intangible value considerations, the product partners can select the best set of high-value product features (options) for the next planning horizon. (In our second article in this series we define options and describe how teams discover them for all 7 Product Dimensions.) To do this, they consider the costs, benefits, risks, dependencies, and value considerations of each option. They then adjust each option’s value up or down accordingly, always ensuring the option is aligned with the product’s vision, goals and objectives.

Together, the desired outcomes, value considerations, benefits, and risks make up the business value model for a product. The product partners use the value model during discovery and delivery to guide their decisions. In the next article in this series we’ll describe how the partners plan collaboratively, choosing decision-making rules and the timing of the decisions, favoring the last responsible moment.

maryellen May13

Adjust Course As Needed

Discovering value isn’t a one-and-done activity. The product partners repeat the process at every planning horizon: the long-term (Big-View), the interim-term (Pre-View), and the short-term (Now-View). Throughout the product’s lifecycle, the partners stay alert to changes in market conditions, availability of resources, costs of delay, etc., and their potential impact on the product, modifying the business value model as needed.

After each delivery cycle, the partners determine if what was delivered actually realizes the anticipated value. This comparison may uncover gaps to be addressed in future releases. Though the Lean Startup movement has made this seem like a new concept, we’ve long had a name for it in requirements engineering: validation. In Discover to Deliver, we call it “confirm to learn.”

Ensure Optimal Visibility

Before value can drive decisions, it must be defined, visible, and well understood by all concerned. Teams need to understand what value means through the eyes of the stakeholders—the product partners from business, customer, and technology. They can then view potential product options (requirements) in the context of these values to choose the most valuable set of features for each release.

When was the last time you collaboratively discussed and purposefully validated your value assumptions? Take some time in your next planning session to honestly and transparently define your product’s value, so that value truly becomes the driving force behind your product decisions.

Don’t forget to leave your comments below.

Gottesdiener, Ellen and Mary Gorman. Discover to Deliver: Agile Product Planning and Analysis. EBG Consulting, 2012.
Hubbard, Douglas. How to Measure Anything: Finding the Value of Intangibles in Business. 3rd edition, Wiley, 2014.
SAVE International. Value Standard and Body of Knowledge. June 2007. Available online here.

Exploring Product Options to Arrive at Right Requirements

When is a so-called requirement really required? And is it the “right” requirement? The answers depend on many facets: stakeholders, value, planning horizon, and so on. This article explores using options as a means to identify high-value requirements, at the last responsible moment.

Our previous article in this series, “Turning Competing Stakeholders into Collaborating Product Partners,” describes stakeholders as product partners –representatives from the customer, business and technology groups who collaboratively discover and deliver high-value product solutions.

My Requirement May Be Your Option

Product requirements are needs that must be satisfied to achieve a goal, solve a problem, or take advantage of an opportunity. The word “requirement” literally means something that is absolutely, positively, without question, necessary. Product requirements must be defined in sufficient detail for planning and development. But before going to that effort and expense, are you sure they are not only must-haves but also the right and relevant requirements?

To arrive at this level of certainty, the product partners ideally start by exploring the product’s options. What do we mean by an option? An option represents a potential characteristic, facet, or quality of the product. The partners use expansive thinking to surface a range of options that could fulfill the vision. Then they collaboratively analyze the options and collectively select options, based on value.

During discovery work, the partners may find that some members see a specific option as a “requirement” for the next delivery cycle, whereas others consider it a “wish list” item for a future release. Such was the case in a recent release planning workshop. The team wrestled with a particular option, questioning if it could deliver enough value to justify the cost to develop it. The product champion explained why the option was a requirement—without it the organization was at risk for regulatory noncompliance. Once the others understood this, they all agreed it would be included in the release.

In a different planning workshop, the systems architect raised the option of using biometric technology to reduce security threats. After carefully considering a variety of factors, including the cost and organizational readiness, the team chose to defer the option.

Count to Seven

Both agile and non-agile teams often unconsciously limit analyzing the options. Many teams zero in on stories, learning about the users and their actions. Other teams dig into processes or data, or sometimes both of them. But every product has multiple dimensions, seven in fact. Discovering options for each of the 7 Product Dimensions yields a comprehensive, realistic view of the product.

Product Dimension Description
User Users interact with the product
Interface The product connects users, systems, and devices
Action The product provides capabilities to users
Data The product includes a repository of data and useful information
Control The product enforces constraints
Environment The product conforms to physical properties and technical platforms
Quality Attribute The product has certain properties that qualify its operation and development

Table 1: The 7 Product Dimensions Yield a Comprehensive Understanding of the Product

The previous article in this series described the Structured Conversation, where the stakeholders, acting as product partners, explore product options across the 7 Product Dimensions, evaluate the possibilities, and make tough choices based on value. Remember, every product option cannot be delivered right now.

Exploring across these 7 Product Dimensions prevents difficult downstream problems. A recent client was struggling with just such a blockage. Running their product on multiple platforms was causing delays that put them behind in their market. As they explored the Environment dimension, they considered browsers and database management systems possibilities. Their analysis factored in the most valuable options from the other six dimensions, including the location of the users, the actions that would be supported and the necessary data. They then selected a cohesive set of options across the 7 Product Dimensions to craft a candidate solution. They were able to make what had once seemed a difficult decision in a matter of minutes. By exploring across the 7 Product Dimensions, their painful problem was resolved with a clear, holistic set of requirements.

gottesdiener Feb25 2

Figure 1. A product encapsulates a cohesive set of high value options
Image Source: Discover to Deliver: Agile Product Planning and Analysis, Gottesdiener and Gorman, 2012

Look Far and Near

The partners need to realistically determine when an option will deliver its greatest value.
Our previous article in this series outlined three planning views. The timeframes may vary from team to team, but general speaking they are as follows:

  • The Big-View is the long-term view or product roadmap (generally one to two or more years). The partners envision generalized, high-level options for the product. Options for the big-view could be considered “boulder” size, or in user story terms, as epics.
  • The Pre-View focuses on the next product release (say one or two months). To continue the analogy, these options are “rock” size, or user-story size.
  • The Now-View concentrates on the next product increment (from a day up to a month). The selected options are fine-grained, “pebble size” and defined in sufficient detail for development. They are no longer options but requirements, ready for immediate development.

An aside: We have used the “boulder, rock, pebble” analogy for many years to distinguish granularity in each view, for each of the 7 Product Dimensions.

An agile team keeps the product options “open.” In each view they wait until the last responsible moment to evaluate the options’ value and allocate high-value ones to the next planning horizon. They are prepared to adjust their choices for a variety of conditions, including changing market conditions, emerging technologies, and so on.

From Options to Requirements

Discovering product options enables the product partners to collaboratively and creatively explore a range of possibilities. This expansive thinking opens up product innovation, experimentation, and mutual learning.

By holistically exploring options for the 7 Product Dimensions the partners grasp the entirety of the potential range and can choose the options that deliver the highest value. Using the appropriate planning view (Big, Pre, Now), they narrow the scope. When an option is allocated for immediate delivery it is consider a requirement.

As a recap, we characterize a “right requirement” as one that is:

  1. Just in time, just enough. It is essential for achieving the business objectives, in this time period.
  2. Realistic. It is capable of being delivered with the available resources.
  3. Clearly and unambiguously defined. Acceptance criteria exist that all partners understand and will use to verify and validate the product.
  4. Valuable. It is indispensible for achieving the anticipated outcomes for the next delivery cycle.

In this series’ next article we focus on value—how the product partners define and use value to select options needed to deliver high-value products.

Don’t forget to leave your comments below.

About the Authors:

mbgMary Gorman, a leader in business analysis and requirements, is Vice President of Quality & Delivery at EBG Consulting. Mary coaches product teams and facilitates discovery workshops, and she trains stakeholders in collaborative practices. She speaks and writes on Agile, business analysis, and project management. A Certified Business Analysis Professional™ and Certified Scrum Master, Mary helped develop the IIBA® Business Analysis Body of Knowledge® and certification exam, and the PMI® business analysis role delineation. Mary is co-author of Discover to Deliver: Agile Product Planning and Analysis.

egEllen Gottesdiener, Founder and Principal of EBG Consulting, is a leader in the collaborative convergence of requirements + product management + project management. Ellen coaches individuals and teams and facilitates discovery and planning workshops. A Certified Professional Facilitator and a Certified Scrum Master, she writes widely and keynotes and presents worldwide. In addition to co-authoring Discover to Deliver: Agile Product Planning and Analysis, Ellen is author of Requirements by Collaboration and The Software Requirements Memory Jogger.

Turning Competing Stakeholders into Collaborating Product Partners

On time. On budget. Error free. These are crucial delivery goals for any organization. Yet they are rendered almost meaningless if the product fails to deliver value.

That’s why successful delivery teams work hand-in-hand with their stakeholders as product partners, defining value and then actively discovering — and delivering — high-value solutions. This goes beyond feature requests and requirements documents—beyond user stories and product backlogs—beyond the push-pull of competing interests. It’s a partnership where the ideas, perspectives and experiences of three different stakeholder groups converge. The result? Product partners who collaborate to discover and deliver value.

Let’s look more closely at these product partners: who they are, how they work together, and how they balance competing priorities.

First Ask Who

A product partnership includes people from three realms: customer, business, and technology. Each offers a unique perspective and has its own ideas of what is valuable.

The customer partners represent users, buyers, and advisers — people or systems that interface with the product, choose to buy it, or influence others to buy it. They tend to value improved productivity, heightened efficiency, greater speed, entertainment, and similar benefits.

Business partners represent the people in your organization who authorize, champion, or support the product or who provide subject matter expertise. They find value in improving market position, complying with regulations, achieving a business case, reducing overhead costs, enhancing internal performance, and so on.

Technology partners (your delivery team, internal or third parties) design, deliver, test, and support the product or advise those who do. They may value building a high-quality product, offering smooth, continual delivery, adopting a stable architecture, and the like.

ellen nov19 img01Figure 1: The Product Partners
Image Source: Discover to Deliver: Agile Product Planning and Analysis, Gottesdiener and Gorman, 2012

This mix of partners and perspectives is essential, no matter what kind of delivery method you adopt (agile, traditional, hybrid, or another approach). For the partnership to work, these three disparate groups, with specific individual titles and roles, must collaborate to reach their shared goal: discover and deliver value. 

Partners don’t see themselves as dependent or independent. Instead, they’re interdependent — mutually reliant on and responsible to each other to reach their shared goal. Acting as partners, they apply their skills and knowledge without regard to their title or role. The lines between product and project management, business analysis, testing, user experience, quality assurance, and development and operations blur.

To Discover, Ask Why

Once the product partner team is identified, the product partners work together to discover which product attributes will deliver value. The key to successful discovery is to keep the focus on value—the why behind each product option. To ensure that all of the product partners understand what is important to each group—each partner’s value considerations—we often find it helpful to write and post the different value considerations in the group space. Business partners, for example, often find that they identify with the acronym IRACIS (“ear ras cuss”). “IR” stands for “increase revenue,” “AC” is “avoid costs,” and “IS” means “improve service.” 

When shared openly, IRACIS and other value considerations become a vital reference point as the partners weigh the value of the product options. As their perspectives and value considerations diverge or compete, they use participatory decision making to reach closure. 

To Decide, Ask When

One factor that has tremendous influence on this decision-making process is when. Asking when helps the partners decide the opportune time a product option will deliver its greatest value. We categorize the product’s planning horizons as the Big-View, the Pre-View, and the Now-View. 

The Big-View is the long-term view or product roadmap (one or two years). 

The Pre-View focuses on the next product iteration or release (a month or two).

The Now-View concentrates on the next product increment (a few days to a month).

The length of the views may vary. One team’s Pre-View (release) might be 2 weeks; some teams (newer to agile and automated testing) have 3 or 4 month release cycles.

ellen nov19 img02Figure 2: The Product Partners
Image Source: Discover to Deliver: Agile Product Planning and Analysis, Gottesdiener and Gorman, 2012

The product partners typically need the most the valuable options to be delivered early in the product’s lifecycle, so when weighing competing product options, they allocate higher priority ones to nearer-term planning horizons. Because the value of a product option can change over time, the partners benefit from having the flexibility to allocate and deliver options at the last responsible moment.

Choose How to Collaborate

It’s not enough to get the right people together and ask the right questions. To communicate efficiently and effectively about how to deliver, product partners need a focused way to communicate and make decisions together. By far the most efficient and effective discovery mechanism is a collaborative approach called the “structured conversation”. In a structured conversation, the product partners first explore possible requirements (options) for their next increment. They then evaluate these many options in terms of value. Once they have narrowed the list of options through the evaluation process, they confirm how they will verify and validate these candidate solutions with unambiguous acceptance criteria. The validation includes how to test that they delivered the right requirements, and that they achieved the anticipated value from each delivery. You can learn more about structured conversations here and in this 7-minute video.

ellen nov19 img03Figure 3: The Structured Conversation
Image Source: Discover to Deliver: Agile Product Planning and Analysis, Gottesdiener and Gorman, 2012

A structured conversation is a lightweight yet disciplined approach to ensure that the team members learn from each delivery increment, gathering feedback and improving their product and process as they go. When the conversation’s scope is the longer-term aspects of the product, a facilitated workshop is a powerful way to discover the product’s big picture. 

All Together Now

True success depends on discovering product value and delivering it. To do this most effectively, you must abandon the mindset of competing stakeholders and instead embrace the concept of collaborating product partnerships, where role and title take second place to perspective and value. By actively engaging as product partners in structured conversations–exploring, evaluating and confirming product options–the stakeholders ensure every product increment delivers the highest value. Their active collaboration also yields a stronger community with effective communications, shared understanding, increased productivity and trust. 

To maximize the effectiveness of your product partnership, keep these points in mind:

  • Include people from the customer, business, and technology realms.
  • Have each partner or group describe and share its value considerations.
  • Frame value decisions within one planning horizon.
  • Hold structured conversations to explore and evaluate product options, and to confirm candidate solutions.
  • Promote interdependence among the product partners. Remember, it’s the goal, not the role.

Don’t forget to leave your comments below.

What’s Down with Agile Documentation?

Recently we worked with an Agile team that was building an FDA-regulated medical device. Some team members were worried about how to produce the required verification and validation documents. “What do we do?” they asked us. “We’re not supposed to do documentation in Agile.”

That’s a myth. In Agile, the question isn’t whether to document. It’s what kind of documentation to create, and when. Like everything else in Agile, those decisions are based on your assessment of value—in this case, the value of the documentation. More documentation is not necessarily better. In fact, the volume of product documentation often is inversely related to its value.

gottesimg01 Aug28Figure 1: Potential Nonlinear Relationship between Documentation’s Volume and Value
Image Source: Discover to Deliver: Agile Product Planning and Analysis, Gottesdiener and Gorman, 2012

Process Versus Product Documentation

You essentially have two types of documentation: process and product documentation. In either case, we urge teams to focus on the documentation’s consumers and look closely at their usage needs. Look at the documentation from the consumer’s perspective, and explore her usability needs to determine the minimum useful and usable documentation.

Process documentation describes the work-in-progress or handover information the stakeholders produce as they discover and deliver the product—the software application, system, or device containing software. Process documentation has less value for a co-located, domain-savvy team than for a team working in a distributed mode in different time zones and with varying degrees of domain expertise. On the other hand, even a co-located team may need process documentation if it’s building a regulated product and requires evidence of product verification, as in our client’s case. 

Product documentation, which conveys information about the product, is an asset that tends to be valuable because it’s used to sell, service, and use the product. Consider that the consumer of your product documentation might be a validation analyst from a regulatory body, a product end user, an installer, a help desk technician, a field staffer, a maintenance programmer, and so on. 

For our medical device client, the product documentation included scripts for a demo used to conduct validated learning to test the product idea itself. We took the perspective of the people going on-site to conduct the demos, and as a result we created a booklet in a slim, tabular format with abbreviated feature descriptions and demo steps. Not only was this booklet “just enough” to document the product, but also it was fast to produce. As a bonus, the delivery team found the format useful for onboarding new team members. 

On Your Mark…

Teams, including the product owners, need to decide when to produce documentation. There are the two meta-patterns: build it incrementally in small bits as you build the software (and when you have the greatest knowledge for creating the documentation), or defer until prior to release (batching documentation as larger set, created all at once).

When the requirements are fairly well known, documenting early and often makes sense. On the other hand, our medical device client was essentially a start-up. The potentially lifesaving devices were being used experimentally with patients in the hospital, and the requirements were changing as the product itself was being tested. This meant that it would have been wasteful to document what the team was delivering at each iteration. They agreed to wait to document prior to each release throughout the experimental usage of the product (this is roughly equivalent to what a lean start-up calls “validated learning”). For this team, it made sense to defer documentation.

A good practice is to produce documentation as part of the acceptance criteria for completing a slice of the product, whether it’s a story, feature, or minimum marketable feature—whatever anchor you use to describe the requirements you’re delivering. When you make the necessary and sufficient documentation a part of the acceptance criteria, you’re gaining value for little added effort.

Sliding Along the Documentation Levers

Consider documentation formality and precision and the volatility of your requirements. Do you need documentation that conforms to a predefined format, sign-off, and so on? Will informal documentation good enough? How precise must the documentation be? Who will be consuming the documentation, and to what end? And as with our medical team, documenting too soon would have been wasteful because of the volatility of the requirements, and yet when it was produced, it needed to be precise and formal.

There is no one size fits all. As shown in Figure 2, different product and project situations influence how you will adapt your documentation plans.

gottesimg02 Aug28Figure 2: Adapting Your Document for Different Products
Image Source: Discover to Deliver: Agile Product Planning and Analysis, Gottesdiener and Gorman, 2012

The Low Down on Documentation

Documentation boils down to knowledge transfer. Where possible, document in chunks, and deliver just enough to serve the needs of the specific consumer of the documentation. In that way, you maximize the value you create for the effort you invest.

Don’t forget to leave your comments below.

Gottesdiener, Ellen and Mary Gorman. Discover to Deliver: Agile Product Planning and Analysis. EBG Consulting, Inc., 2012.

About the Authors:

egEllen Gottesdiener, Founder and Principal of EBG Consulting, is a leader in the collaborative convergence of requirements + product management + project management. Ellen coaches individuals and teams and facilitates discovery and planning workshops. A Certified Professional Facilitator and a Certified Scrum Master, she writes widely and keynotes and presents worldwide. In addition to co-authoring Discover to Deliver: Agile Product Planning and Analysis, Ellen is author of Requirements by Collaboration and The Software Requirements Memory Jogger.

mbgMary Gorman, a leader in business analysis and requirements, is Vice President of Quality & Delivery at EBG Consulting. Mary coaches product teams and facilitates discovery workshops, and she trains stakeholders in collaborative practices. She speaks and writes on Agile, business analysis, and project management. A Certified Business Analysis Professional™ and Certified Scrum Master, Mary helped develop the IIBA® Business Analysis Body of Knowledge® and certification exam, and the PMI® business analysis role delineation. Mary is co-author of Discover to Deliver: Agile Product Planning and Analysis.

It’s the Goal, Not the Role: The Value of Business Analysis in Scrum

In agile development, what happens to the traditional business analyst? Consider Scrum, currently the most popular agile method. In Scrum, there is no “business analyst” role. In fact, there is not an explicit role for tester, project manager, architect, developer, data administrator, user experience designer, customer support representative, or product trainer. Instead, Scrum has three roles: the product owner, the ScrumMaster, and the delivery team. Their collective goal is to deliver high-valued product needs continually. So, where and how can a business analyst contribute?

One possibility is the ScrumMaster role. Great ScrumMasters are facilitative leaders with a diverse set of analysis skills and strong communication and facilitation abilities. In addition, they have a sound understanding of the business domain. Business analysts and project managers with those strong skills are good candidates for the ScrumMaster role.

Another possibility is the delivery team. On some Scrum teams we’ve coached, the business analyst blends into the delivery team, participating and often leading the activities of planning, analyzing, testing, and demonstrating the product. Using Scrum terminology, that work is burned up and burned down, along with the work of design, development, and so on. 

The Business Analyst Is Not the Product Owner, Unless …

The product owner role requires deep domain and product knowledge to guide decisions about what to build and when to build it. The product owner, in collaboration with the delivery team, explores and evaluates product needs to make those decisions. That’s business analysis work. 

The product owner may choose to explicitly and transparently delegate decision-making authority. We’ve seen this responsibility delegated to a business analystwho reports within the business or product management organization and has the requisite domain and product background.

Strategic and Tactical Work of the Product Owner

The product owner role in Scrum is crucial for success. The product owner is responsible for the planning, analysis, communication, and decision making to ensure that the right product is delivered.

 Strategic product owner responsibilities include:

  • Lead customer and product-discovery activities.
  • Create strategic product plans and define business value (product profitability).
  • Communicate the product roadmap and plans to internal and external stakeholders.
  • Develop and manage a lean, dynamic product backlog (also called “pruning” or “grooming” the backlog).
  • Select and analyze product backlog requirements to prepare them for agile planning workshops.
  • Identify themes for each planning cycle.
  • Lead or participate in agile planning and retrospective workshops.

Tactical, day-to-day product owner responsibilities include:

  • Participate in product backlog grooming (e.g., work ahead, make ready, planning, agile analysis, and pruning workshops) to prepare backlog items for estimating and planning.
  • Specify acceptance criteria for each backlog item.
  • Review and approve user stories.
  • Attend daily stand-ups and the end-of-iteration and end-of-release demonstrations and retrospectives.

That’s a lot of responsibility—and it’s time-consuming, to boot. In addition, most product owners wear many other hats. In commercial software organizations, they may be product managers. Or, in organizations that develop software to support their internal IT operations, product owners may be mid- or senior-level business managers. No wonder the product owner needs help! 

Balancing Strategic and Tactical Work

In our experience, many product owners don’t have time to balance the strategic responsibilities with the tactical work needed to sustain a healthy flow of delivery. A time-pressed product owner has the following options:

  1. Do it all (sometimes not very well, causing bottlenecks and delays).
  2. Establish a product owner council headed by an über-product owner, with strategic responsibilities distributed among the members.
  3. Get help with the tactical analysis work. Rely on the folks on the delivery team to do much of the business analysis, and retain strategic and tactical decision-making authority.
  4. Retain strategic responsibilities and delegate the tactical work to someone else (e.g., a domain-savvy business analyst). This delegation should be explicitly and transparently communicated to all stakeholders.
  5. Some combination of the above.

Beyond Roles to Goals

After exploring and evaluating requirements options, the goal of analysis is to allocate the highest-value requirements for delivery. No matter how roles are classified on your agile team, that business analysis work is vital. It is best done collaboratively, leveraging everyone’s skills to build and maintain a shared understanding of product needs.

Above all, it’s the goal, and not the role, that matters.


Product Owner Role

  • Pichler, Roman. Agile Product Management with Scrum: Creating Products That Customers Love. Addison-Wesley, 2010.
  • Schwaber, Ken, Product Owners Not Proxies.” 

Agile Analysis

This article was originally published on TechWell and Agile Journal, August 2011

Copyright © SQE, 2011

Don’t forget to leave your comments below.

Ellen Gottesdiener helps business and technical teams collaborate to define and deliver products customers value and need. Ellen is an internationally recognized facilitator, trainer, speaker, and expert on requirements development and management, Agile business analysis, product chartering and roadmapping, retrospectives, and collaborative workshops. Author of two acclaimed books Requirements by Collaboration and The Software Requirements Memory Jogger, Ellen works with global clients and speaks at industry conferences. She is co-authoring a book with Mary Gorman on agile practices for discovering and exploring product needs. View her articles, tweets, blog, and free eNewsletter on EBG’s web site.

Mary Gorman, CBAP, CSM, and VP of quality & delivery at EBG Consulting helps business and technical teams collaborate to deliver products your customers value and need. Mary works with global clients, speaks at industry conferences, and writes on requirements topics for the business analysis community. She is currently co-authoring a book with Ellen Gottesdiener on essential agile requirements practices.