Guest post by Ellen Gottesdiener: 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.

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

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.

7 product dimensions

Look Far and Near

The partners need to realistically determine when an option will deliver its greatest value.
In a related article, we 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:

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

Ellen Gottesdiener and Mary Gorman

Did this sound interesting? Sign up for Ellen’s training “Agile Requirements Analysis and Planning for Product Success in September!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.