Slice Value, Not Functionality.

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”>