Product Owners often struggle to make stories small enough. Agile projects end up with “MVP”s that take the team months to build. The solution to this problem is to slice value rather than functionality, but what does that mean?

Traditional projects often have a “scope”. “Scope” normally means “As an investor I have given you this much money for this set of functionality”. As a result, product owners and business analysts often focus on the functionality of the product rather than the value of the product to the customer or user. This leads to all sorts of problems. Consider the example where an investor wants to deliver a portfolio of products to their customers. That portfolio consists of a cup of tea, and a cup of coffee. The functionality required is that the project needs to develop the capability of delivering a cup of tea, and a cup of coffee.

To me, the business analyst toolkit is focused on delivering capability (or functionality) within an organisation. By contract, the product management toolkit focuses on satisfying the needs of the customer. The product owner needs both of these tool kits in their product owner team in order to be successful.

Slicing Functionality

The first problem when we slice functionality is that the definition of the product to satisfy the needs of the customer is subjective. I worked on a project where we had to deliver a “cup of coffee”. Before we delivered the product, we had a long series of  reviews with the chief product owner where they gave feedback. One chief product owner would say “Too bitter!”, and the other would say “Not bitter enough”. The project had delivered a cup of coffee but the acceptance criteria were not clear enough. This is a failure state that product owners often find themselves in.

The other problem is the variants. The scope said that we needed to deliver a cup of coffee but all of a sudden, we discovered lots of variants. We need Cappuccinos, Americanos, Lattes and Macchiatos. We need coffee delivered in paper cup, and china cups, and tall glasses. We need full fat milk, semi skilled milk, skimmed milk, rice milk, lactose free milk, and soya milk. Whenever we speak to the investor (sponsor in Corporate speak to indicate they are investing someone else’s money), they insist we have to include whatever niche variant because they know someone who drinks it, or might want to drink it. “Bob in marketing drinks double double decaf upside down with a twist of vanilla in a bring your own sports cup with straw.”

Whenever you try to reduce the scope, it increases as you make the investor aware of a gap in their original thinking. Whenever we think of a variant, our investor thinks of someone who might need it. Our “scope” balloons out of control and we end up with massive releases.

Slicing by Value

Slicing by value makes it much simpler to create small stories. Instead of functionality, we aim to improve a business metric by satisfying the need of a customer segment (or persona). For example, our organisation has three top level metrics, “Number of Customers”, “Activity”, and “Revenue”. Based on the current portfolio of metrics values, the chief product owner agrees with the product owner which metric it would be best to invest in. The product owner team then identifies those customer segments and needs that would most likely deliver on the metric. Alternatively the product owner team might identify the best investment to make based on their understanding of the customer segments and their needs, and then agree the metric with the chief product owner.

Now the product owner team can be much more focused on the delivery of the cup of coffee. We are looking to “increase revenue by focusing on commuters who have a need for habit and ritual in their commute”. We can also agree measurable acceptance criteria, say 50% of twenty commuters tasted rate the coffee ten out of ten. Now we have our design brief (Metric, Customer Segment, Need), we can create a set of designs. Each design is a hypothesis that might satisfy our design brief. After initial team and user (in)validation (See Melissa Perri’s Bad Idea Terminator), each design becomes an Epic that feeds into the Agile Development Process. An Epic might be needed to create the output of the system that is used in User (In)validation.

Small Stories

So if you have a problem with “stories” that are mammoth beast, try slicing them by value instead of functionality.

Use the “Design Brief” format of

• In order to move <metric>
• As a <customer segment>
• I need <job to be done>

And the Epic Format

• In order to move <metric>
• As a <customer segment>
• I need <job to be done>
• With the hypothesis that <“Functionality”> will satisfy the need

This is so much better than the format

• As a <customer segment>
• I need <“Functionality”>
• So that <“Don’t know what to write here, so I’ll ignore this bit”>

Behaviour Driven Development is like Jazz. It is a constantly evolving approach to communication between all those involved in the specification and delivery of value in software development. Aslak, the creator of Cucumber, has cut a vinyl called “Kind of Green“. As the co-creator of the Given-When-Then format, this is an MP3 I knocked together in my bedroom. Its not quite my vinyl, more of a sample.

As a coach I spend most of my time with Product Owner Teams and Managers in large enterprises with established products, normally with millions of existing customers. The product team who create the stories, or the “Three Amigos” consists of the Product Owner (Product Owner, Chief Product Owner, Product Director), A developer, A testers,…. and A business analyst, architects (business, technical, and security), UX Researchers, UX Designers, System Designers (Lean Services representing the call centre), Data Analysts, and the occasional tastapod. I find the tester is normally best placed to facilitate the “Three Amigos” session.

Top Tip 1: Start with the value

Most product investments start with a “Tea Bag”, a partially formed idea. No one ever wants a tea bag. The conversation goes like this:

• Someone: “I want want a tea bag!”
• Product Owner: “Why?“
• Someone: “Because I want a cup of tea”
• Product Owner: “Why?”
• Someone: “Because I’m thirsty and cold and its a habit OK?”
• Product Owner: “What customer segment does this someone represent?”
• UX Researcher: “The are a commuter, represented by Warren the Worker”
• Product Owner: “So if we meet this need for the Warrens, we should increase activity in our stores.”
• Chief Product Owner: “Activity is a good and righteous metric to move given the current state of our metrics.”

The role of the Chief Product Owner is to ensure that the Product Owner is investing in the right metrics. They ensure alignment across the portfolio. They are an optional member of the product owner team.

• Product Owner: “We will deliver a cup of tea to satisfy the habit and thirst need of Warrens to drive up in-store activity”
• Lean UX Smarty Pants: “Isn’t that like a whole load of hypotheses?”
• Cynefin Smarty Pants: “And that is why we will engage in multiple safe to fail experiments, some of which are oblique.”
• Agile Coach: “That means small Stories and Epics, respond to feedback from real customers.”

The “Find the Value” activity can involve the whole team, however the risk associated with certain aspects is owned by certain roles:

1. The product owner owns the risk that the investment should be moving an appropriate metric.
2. The Chief Product Owner owns the risk that the right metric is being moved given the wider organisational metrics.
3. The UX Researcher / Data Analyst owns the risk that the right customer segment / persona is identified.
4. The UX Reseacher owns the risk that the customer need identified is done so in appropriate manner.

The output of the “Find the Value” Activity is a design brief.

The design brief consists of:

1. The metric to be improved.
2. The customer segment / persona.
3. The need to be satisfied.

At this point, the chief product owner and product director can check to ensure that the investment is aligned with all the other investments in the portfolio.

Please note that this is quite a long post and I still have not got to the bit where talk about user stories and given when then scenarios. You need to do the “Find the value” step first, otherwise as the Cat from Cheshire would say “If you don’t know where you want to go, any way is just as good.”

Top Tip 2: Work Backwards

Once we have a design brief, the entire team can engage in creating designs to satisfy the brief. The UX designer owns the risk that the design process is righteous and good, even if non designers are involved, especially in the original brainstorming.

The first step moving backwards is to start with the need and take one step backwards to consider the output of the system that will satisfy the need of the customer. (The value to the customer is in the output of the system, the need that it satisfies). When we have a design, we can test it on users to get early feedback.

Consider an app that is a music version of IMDB. An example design brief might be “Increase number of customers (metric) for super users (User Segment / Persona), by meeting their need to know where significant events occured for one of their favourite artists.“. The designs that satisfies that output might look like the following, one of which has been discarded as a result of user testing. The user testing has suggested we are best focus initially on the design on the right.

There are two considerations when working backwards from the design. The first is the data that needs to be displayed on the output which is covered by information smells (article video). The second is the behaviour of the application, which is normally expressed using the Given-When-Then format.

Note that identification of data is a complicated problem that is the domain of the business analyst and the architects. There is a right, knowable answer that can be verified by research using information smells.

The behaviour of the application needs an understanding of the value to be delivered, the needs of the customer segment, the technical constraints, and the possible failure states, or “quality” paths. As a result, all of the product owner team should be involved at various points.

When specifying the behaviour of the application, the team should start with the output, which means the first thing they should write is the “THEN“. For example:

• THEN the app displays a map
• AND the user location
• AND the location of any “Lady Gaga sites”
• AND the description of any “Lady Gaga sites”

The product team can then discuss the ways that the user would access the output. What event would cause it to be displayed. There may be several. The ones that are not an initial focus become TODOs that become part of subsequent Epics.

• WHEN the user is within one mile of an “Lady Gaga site”

1. TODO: When the user selects map from “Lady Gaga” page

The “Three Amigos” product team can then create the Conditions necessary, or GIVENs.

• GIVEN the user has selected “Lady Gaga”
• AND there are “Lady Gaga” sites within a mile
• AND the user has enabled notifications on their phone
• AND the user has enabled GPS

Out tester with a black hat is recording the quality paths as TODOs for other Epics:

1. TODO – Lady Gaga not selected
2. TODO – Notifications not enabled
3. TODO – GPS not enabled

The product owner decides the tester can handle 1 and 3 on their own but wants to be involved in 2 as the product owner would like to design an e:mail to tell users what sites they missed.

Which gives us the following first scenario:

• GIVEN the user has selected “Lady Gaga”
• AND there are “Lady Gaga” sites within a mile
• AND the user has enabled notifications on their phone
• AND the user has enabled GPS
• WHEN the user is within one mile of an “Lady Gaga site”
• THEN the app displays a map
• AND the users location
• AND the location of any “Lady Gaga sites”
• AND the description of any “Lady Gaga sites”

The product team then takes each of the GIVENs and turns them into a THEN as they continue to work backwards:

• THEN the user has selected “Lady Gaga”

The event that triggered that was:

• WHEN the user selects “Keep me informed of nearby Lady Gaga sites”

In the following conditions

• GIVEN the user is on the Lady Gaga page
• AND the user is logged on

Top Tip Three – GIVEN-WHEN-THEN first, stories second.

The product owner team can then slice the Epic into Stories.Starting with the GIVEN-WHEN-THEN, work out which bits of the Epic are the riskiest to complete.

• GIVEN the user has selected “Lady Gaga”
• AND there are “Lady Gaga” sites within a mile
• AND the user has enabled notifications on their phone
• AND the user has enabled GPS
• WHEN the user is within one mile of an “Lady Gaga site”
• THEN the app displays a map
• AND the users location
• AND the location of any “Lady Gaga sites”
• AND the description of any “Lady Gaga sites”

The developer and architect might suggest starting with the map as they have not used the map service before. Or they might suggest the “Lady Gaga sites” because that uses a service on the new untested architecture.

The tester might suggest the location trigger (WHEN) because they are not sure how to test it effectively.

The UX researcher might suggest the location trigger (WHEN) because they are unsure how users will respond and they want to test it with a screen mock up.

The security architect is worried about whether people will enter bogus artist sites to spam friends or enemies.

The team orders the stories with the riskiest first. They do the story that is most likely to fail so that they can get quick feedback.

Note that this different to the way that many people advocate. I am suggesting you create the GIVEN-WHEN-THEN scenarios for the design first and then create the stories whereas most other people advocate creation of the stories and then the GIVEN-WHEN-THEN scenarios.

Bonus Top Tip – Micro-Service Design

Starting with the output makes the design of micro-services easier as well. You start with the last thing to be displayed. To do that, you need look no further than your THENs and combined them with your domain model generated using information smells. The input to the last service becomes the output of the preceding service.

• THEN the app displays a map
• AND the users location
• AND the location of any “Lady Gaga sites”
• AND the description of any “Lady Gaga sites”

1. getMap (Location)
2. getArtistSiteDescription (ArtistSiteLocation)
3. getArtistSiteLocations (UserArtistList)
4. getUserArtistList (UserId)
5. getUserId(Username, Password)

Hopefully working backwards will rid the world of projects where the Login screen is the first thing developed.