The exploratory cube and the 8 product dimensions’ game is a powerful tool that makes it possible for Agile Coaches, Scrum Masters, Consultants, Product Owners and anyone related to a product to understand the best way to focus all the efforts towards the delivery of high business value. Although it was initially created for software products, the exploratory cube can be used with any tangible product as most of the modern organisations are digital, which means that their strategies are based on the direct outcome of a piece of software. But before seeing how it works, let me explain to you why the game is needed.
Did it ever happen to you that an Agile team had no idea how to start with a new product, how to slice a high level user story or which options were more valuable for the client?
In my opinion, this is generally due to several factors, among which I normally see the following ones:
- Team and/or Product Owner are new to the company
- Unfamiliarity with the product
- Cognitive bias (they believe that they know more than they actually do or Dunning-Kruger effect)
- Political issues in the company which makes the Product Owner get some extraordinary pressure from different areas of the organization with conflicting goals but equal priorities
- The result of a team working only with technical requirements and not knowing how to properly write user stories from a business point of view
- As a result of just analysing a few dimensions of the problem instead of having a multidimensional conversation
In these cases, results are often very ambiguous, contradictory or huge user stories are created as a result of unfruitful talks during long refinements’ sessions.
This generally leads to many teams confirming what is needed to be developed in the middle of the Sprint, thing which obviously impacts the morale and jeopardizes the ability to complete the expected features on time (expectations).
You will agree with me that it is vitally important to focus all the energy on being assertively correct, that is, just centre in the conversations’ dimensions that enable the business and those responsible for implementing the solution to be on the same page. A set of techniques that are structured, creative, generate consensus among all the people involved are needed to make it possible to easily guide the thinking processes towards the aligning of the organization with the highest possible business value outcome.
We usually have different points of views (marketing, customer service, political constraints, etc.) for the same product, thing which also overflows the amount of information brought to the first meetings.
As an example of that, I had a few months ago to work with two Products Owners who led different teams responsible for exactly the same product. Both had different interpretations and priorities for the same features, making it very difficult to coordinate the groups and/or self-organisation and blockades. This obviously undermined the developers’ confidence and lead to deficiencies in the development life cycle as it added complexity when both Product Owners wanted to expose their ideas about the product.
I will intentionally leave technical issues, size and dependencies, to focus exclusively on the 8 product dimensions, thing which help promote a multidimensional discussion of the Product Backlog.
Using the 8 product dimensions allows you to create a consistent product backlog. This will increase productivity and Team’s morale and establish a common ground for talks related to priorities, objectives and consistency.
The 8 dimensions are used during a exploratory session, that is, a meeting involving the Product Owner, Development Team, Stakeholders and Customers to help identify some key areas and possible options. I use the word «options» as for a single problem might be hundreds of different solutions (options), and the product success is strictly related to the ability to choose the ones which will produce the greatest impact to the user, developed in the shortest possible period of time with high quality and fulfills all the definitions of done.
An exploratory sessions follows a particular structure and uses an exploratory cube. They can be run every a few weeks or part of a refinements. The idea behind this is to teach all members about the different areas needed to get a Product Backlog ready to be consumed (*).
(*) According to a research from Scrum Inc., teams which start the Sprint with a ready Product Backlog double their productivity.
Let me put you an example of how it works; the Product Owner brings a high level user story (Epic) to the meeting, such as:
«As a Frequent flyer I want to be recognized as someone special»
This is a good starting point but really high level for a team to be developed. The main reason is that just covers 2 dimensions: The Customer (1st Dimension) and ambiguously the desired Action (dimension 2).
What does it mean to be recognized? What does it entail to be special? This is a usual situation in an early discovery process and where teams get generally lost. We know that a Frequent Flyer wants to be recognized as a special human being, be spoiled and hugged, but many conversations are needed in order to reach a point where everyone feels comfortable about going ahead and developing the solution.
The biggest challenge for most teams is to focus its efforts on building clarity, something concise, and able to choose the option with the highest business value that can be iteratively developed within a Sprint and great user experience.
Each of the eight cube dimensions makes it possible for people to focus on the different areas to be dissected. Let’s now take a look at the different areas:
Each one promotes a specific type of conversation during the session and all of them will become part of a Product Backlog ready to be consumed.
There are functional elements (Customer, Data, Actions and Controls) and non-functional ones (Interface, Experience, Environment and Quality), however, they all become part of the same discovery process.
To have an effective session, you need to gather in one place all the relevant stakeholders, customers and Team to analyse in a collaborative way the 8 different dimensions.
Each element also contains a clear visual sign that can be kept as an information radiator after the meeting and used for further discussions.You should remember that the idea here is not to use this information to write extensive specifications but to enable people create a common understanding and make sure that the essence of each dimension that solves a specific problem is captured.
Those can be then moved into a set of high business value user stories as seen below:
We normally write the Customer, Actions and Controls dimensions at the front of the card using the classic user story syntax, while the other dimensions are placed at the back.
How is the exploratory cube used and how can the session be run?
Click here to download the instructions and cube and begin to establish all the relevant conversations about the product and its possible solutions.
Many thanks to EBG Consulting for its initial approach.
Thanks for listening,
Erich.
