Agile development works very well in the product development area. But to build a successful product is much more work than just gather requirements and implement them.  One of the trickiest things in agile development is how to prepare requirements that are ready for incremental development while still delivering some value for the customers. Businesses need to constantly deliver new functionality to survive. Customers want new functionality or fix defects (at least). But continuous development can mean waste as well, continuous rework.

In this series of articles, we are going to guide Product Owners on how to prepare a product backlog appropriately.

Let start with Cute.CRM – customers relations management application example in which we want to explain how to write such user story correctly and to describe the thinking process

A business model with Lean Canvas

Most of the Product Owners start to write requirements immediately. This is, however, not correct.

Before we will do so, the business model should be described in a way so I, as the Product Owner, understand who is my customer and her problems. We are going to fill up some parts of the Lean Canvas which are important for our requirements.

  • Customer segments – for who we are going to prepare the product, who is going to buy it, who is preferred as a user of it.
  • Problem – description of 3-5 top problems our customers face.
  • Solution – what the product be will, what will be included in the product
  • Uniqueness – what makes your product different comparing to the competition.

So let say that our example’s lean canvas would look like this one (not all information are necessary for purposes of example so they are empty):

Lean Canvas example product metrics channels market segments

Elevator Statement

To simplify the canvas let’s write down the elevator statement so we can have a crisp description for anybody who is interested.

For small, local market, shops who are a place for shopping with a close buyer-seller relationship

the product Cute.CRM is customers management relationship application that helps keep evidence of sale

and comparing to XYZ helps shops to target theirs offering the way customers feel like VIP.

The Value Proposition Canvas

Now we targeted our application for small companies selling some goods on the local market. But who is such a company? What is its job, what kind of pains they have? What are they looking for?

We need to understand that before we will identify requirements, so we can target the customer much better. We are going to use Value Proposition Canvas for that.

Start - CRM example - value proposition canvas pain gain example

As we know more about our customer, let’s identify what our product should offer to her. We will fill up the left part of the value proposition canvas – gain creators and pain relievers.

Value Proposition Canvas pain relievers gain creators example

Product Backlog

Once we identified product requirements, we can start building up our product backlog.  We will start with three main application areas which in agile are called epics:

  1. Customers epic will be focused on functionality describing a customer, her needs & preferences, etc.
  2. Products epic describes offered products that small local shop sells
  3. Sales epic will provide the functionality necessary to keep the track of sales, their measurements, etc.

Start - CRM - product backlog epics agile product example

To evidence epics, we are going to use SProductDesk which offers a story map view where we will be able to track the hierarchy of the requirements. We colorized cards to distinguish the application’s parts. Learn more how to use ScrumDesk story map.

Breakdown of epics

As the Product Owner, I should break down epics now into more detailed features that combine customer’s jobs, pains and business value together. We broke down epics into features that group user stories (business requirements).

Start - CRM - product backlog - user stories map agile product example

As we apply principle As late as possible, we wrote just titles for the requirements. The reason is simple. Requirements might change, or even they can be removed from our product over time so we do not want to spend life on details right now.

Conclusion

We started to build the new product Cute.CRM with an understanding of the business, potential customers and our uniqueness with help of Lean Canvas. Based on that we synthesized the Elevator statement which provides a crisp description of our business. We continued further with the description of customer’s jobs, pains, and gains with help of Value Proposition Canvas. Only after that, we identified requirements which were later broken down into epics, features and user stories.

We are going to continue with user stories writing. All written user stories will be built upon all mentioned assets and they are going to be validated by all of the assets.

AGILE PRODUCT Infographics