Converting Product Concepts into Backlog Items

© 2012 William Patrick Swisher

One of the more challenging aspects of Scrum for new Product Owners is the process of creating backlog items from product concepts. While the level of detail necessary is similar to what’s required for Waterfall development, they are packaged up differently and require a different approach. Under Scrum, the focus is on discrete units of business value and engagement of the Developers to realize the desired goals. So, instead of a long list of granular requirements defining functionality and characteristics, the emphasis is on describing the business value in terms of user experience and the specific criteria by which it will be judged once the work has been completed. The following describes a practical way to decompose product ideas into discrete units of business value, commonly known as backlog items.

Step 1 – Write an Elevator Pitch:

Define the product concept in a succinct form that anyone will understand what the ultimate objective is. This exercise can be thought of as writing an ‘elevator pitch’ where you have to convey what the product is, what it’ll do, who will use it, and why it will be of value to customers. For example:

“www.myutilities.com, a subscription based website that provides utility customers (i.e.: gas, water, electricity) with a single interface to view information about their accounts, analyze usage patterns, download historical reports and get conservation tips so they can manage their household costs better.”

The process of creating this description will actually help the Product Owner solidify in their own minds what the product is supposed to be. For those readers familiar with Scrum already, you may notice the format looks a lot like a user story and that is no coincidence since the format is excellent for conveying the business value in plain language.

Step 2 – Define the Features:

Define the features as the customer would experience them and create a bulleted list. This is where the process gets tricky, the Product Owner must avoid listing specific functionality or characteristics and describe the features in terms of the value they provide to the customer. It may help to think about how the product would be marketed or the advertisement copy written to highlight features that would attract a customer’s attention. Using the http://www.myutilities.com example above, the feature list would be:

  • Historical usage reports.
  • Safe and secure login.
  • Customizable dashboard view of all utility accounts.
  • Quick and easy enrollment process.
  • Automatic utility data updates.
  • Utility specific pages with summary and detail information.
  • Usage analysis and conservation tips.

This list represents what the backlog items are but at least one of them seems a bit too ambitious and certainly not describing a discrete, single benefit for the customer. In Scrum parlance, this would be called an Epic, as in, containing more than one user story. The following feature appears to be an epic and will need to be broken down further:

  • Customizable dashboard view of all utility accounts.

A user configurable dashboard is a concept we’re familiar with, hence the error of considering it discrete but the line is really describing at least two separate things:

  • A single webpage displaying information from the different utility accounts.
  • The ability for a customer to control what data will be shown.

After splitting the concepts up, the feature list should be expanded to include:

  • Dashboard showing all utility accounts.
  • Customization option to change dashboard data elements.

These seem like the right level of granularity as they now describe discrete features.

Step 3 – Order the Features:

Once each of the features listed have been evaluated and if necessary, split up, the entire list should be ordered according to the business value they provide. Even if the Product Owner cannot imagine declaring the product ready for customers until all of the listed features were included, the list should be sorted. Doing so is relatively easy if they ask themselves the question: “If I could only have one feature delivered today, which would it be?”. The Product Owner may have to consider the needs of the market, return on investment, political considerations, and their own desires but ultimately one will be chosen. The question is asked repeatedly until the list is assembled in business priority order.

  1. Quick and easy enrollment process.
  2. Safe and secure login.
  3. Automatic utility data updates.
  4. Dashboard showing all utility accounts.
  5. Utility specific page with summary and detail information.
  6. Customization option to change dashboard data elements.
  7. Historical usage reports.
  8. Usage analysis and cost savings tips.

Ordering the features is important because it defines the order of the Product Backlog which in turn represents the order that the Developers will complete the work. If project resources were cut unexpectedly the work delivered up to that point would be the most valuable and potentially enough to launch the product with.

Step 4 – Write User Stories & Acceptance Criteria: 

User Stories

At this point the Product Owner should write user stories for each backlog item in order to further describe the business value from the perspective of someone who will use it. A user story provides context around what is sought, who will use it, and why they want it. They are typically written according to a specific format:

As a <role>,

I want to <action [or] experience>,

so I can <explanation of why>.

It may seem silly but this effort actually helps the Developers understand the goal of each backlog item. When they are engaged to achieve the goal, and not just take orders, their participation in this way may result in valuable suggestions. Using the first business priority feature from the ordered list described in step 3:

  1. Quick and easy enrollment process.

The user story might be:

“As a potential customer, I want a clear, short, and easily completed enrollment process so I can start using the product right away.”

This simple sentence conveys what the user experience ought to be and so the Developers can help the Product Owner fill in the details to achieve the objective.

Acceptance Criteria

In addition to user stories, the Product Owner must define the specific functionality and characteristics for each backlog item. These requirements are written as acceptance criteria and not only explain what should be coded and tested but serve as a checklist for the Product Owner to verify the work during the Sprint Review meeting.

Acceptance criteria should be stored as a numbered list of singular, unambiguous and testable descriptions of functionality or characteristics. Having a numbered list is important because multiple people will reference these items and need to call them out specifically in conversations and email. For example:

  1. The enrollment page must use HTTPs.
  2. The username must be between six and 12 characters and contain at least one letter.
  3. If the username doesn’t meet the minimum standards, the following error message must be displayed: “We’re sorry but the username must be between six and 12 characters long. Please try again.”
  4. The password must be at least 8 characters and include letters, numbers and special characters.
  5. If the password doesn’t meet the minimum standards the following error message must be displayed: “We’re sorry but the password must be at least eight characters long and include letters, numbers and special characters (e.g.: #%^&@. Please try again.”

For a complex backlog item, the list of acceptance criteria could be long and if so, the Product Owner might consider if it was too ambitious to begin with and could be split up along logical lines.

Notice also that the language of each acceptance criteria is very direct. The word “must” is used versus “shall” or “should” because it should be very clear what is expected. After each criterion is written, the question should be asked: “Is this clearly describing a single requirement and can be demonstrated as complete?” If there’s any doubt, then the criterion should be refined until the answer is ‘yes’.

Step 5 – Define a Release:

The final step in breaking down a product concept into business value is to look at the ordered list of completed backlog items and decide at which item would there be sufficient business value delivered to be able to bring the product to market. For example:

  1. Quick and easy enrollment process.
  2. Safe and secure login.
  3. Automatic utility data updates.
  4. Dashboard showing all utility accounts.
  5. Utility specific page with summary and detail information.
  6. *****Everything above this line is in Release v1.0.0*****
  7. Customization option to change dashboard data elements.
  8. Historical usage reports.
  9. Usage analysis and cost savings tips.

Everything above that line is absolutely essential to call it a first release and everything below it is optional. As the list of backlog items change over time, the Product Owner should maintain the placement of the release line, making sure that any new backlog item added resides in its proper place.

At this point the Product Owner has a viable Product Backlog describing the original product concept. They are by no means done editing as interaction with the Developers will yield questions, suggestions, and changes to many backlog items and their associated user stories and acceptance criteria.

Advertisements
This entry was posted in Backlog Items and tagged , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s