Chapter 1: Problem Statements, Goals, and

Success Measures
At the end of this chapter you will know how to:
 Understand and create a problem statement
 Understand and create a goal
 Understand and create success measures

Part 1: Problem Statements

A problem statement is a concise description of the issues that need to
be addressed. In this case, it’s a description, or a set of descriptions of
issues faced by prospective users of your product.
Why Problem Statements Are Important
Problem statements are important to the backlog because they help
guide the product vision and align the end-state of the solution with the
problem. Anytime we are considering a feature or a prospective
feature, we can always refer back to the problem statements to
understand the problems, assess the impact of that solution on the
problem, and prioritize accordingly.
Example of a problem statement
In order to become the global leader in widget management software,
ACMEcorp needs a product that is stable, easy to use, and responsive.
Today, because our software is so large and configurable, it is not easy
to use. Because of the enhancements and new features that have been
added over the years, sometimes in haste, it is not stable, and because
we have been working off a legacy desktop framework, our software is
not responsive.
The most common customer complaint is the software simply crashing.
The second most common complaint is that we don’t offer a web or
mobile interface for our software.
If ACMEcorp does not improve the stability, responsiveness, and
flexibility of our software, we have no chance in becoming a global
leader. Additionally, more nimble startups with better products take
our customers and eventually our market share.
ACMEcorp will create a new version of our software using modern
software development techniques and practices. This new version will
be web and mobile friendly and will have built-in logging and support
mechanisms to help us spot problems before the customer needs to
call support.

How to create a problem statement

A problem statement is composed of 4 parts:
- The description of an “ideal scenario” or future state
- A description of the current situation
- The consequences of continuing the bad scenario
- What you plan to do to fix the current situation.
In the ACMEcorp example, I first described the ideal scenario as having
a product that was stable, easy to use, and responsive. Starting the
problem statement with a vision of the future state helps us to focus on
the future state by describing it.
Next, I described the current situation and validated it with data in the
form of customer complaints. Understanding the current state in
relation to the future state helps highlight the gaps between where we
are and where we want to be. The gap represents the solution
opportunity. Lastly, I described the solution to the problem statement
answering the question, “whaddya gonna do about it?”
The formula for creating problem statements is as follows: Description
of Ideal Scenario + Reality of Scenario + Consequences of Continuing
Bad Scenario + Solution to problem statement. Next Steps: Create your
complete problem statement based on the above format.

Part 2: Goals
A goal is a way to describe the end state of the solution your team will
be developing. High level goals are important to the backlog because
they help you understand the direction you are going and when you are
there. Without a goal, the backlog and priorities are subject to the
whim of the moment and could possible result in a solution that does
not solve the problem or help us reach our goal.
Examples of goals
 Goal 1: To create a solution that works well with both web and
mobile
 Goal 2: To create a solution that can work on any platform with a
common backend for all platforms
 Goal 3: To create a solution with a more intuitive user interface
 Goal 4: To create a solution that is more stable
How to Create Goals
 Step 1: List the problems identified in your problem statement
 Step 2: Brainstorm goals that would represent an end state that
would solve the problem
 Step 3: List the goals in the form of “to….” As in “To create a
solution that works well with web and mobile”
Part 3: Success Measures
A success measure is a quantifiable measure that helps you qualify
whether or not the project’s efforts are successful. Success measures
are important because they can help you calculate the ROI associated
with the projects efforts. Success measures are also important because
they help you understand when you have succeeded.
Examples of Success Measures:
 Reduce customer support calls by 50%
 Increase Net Promoter Score by 20%
 Reduce crash reports by 80%
Notice in all the examples above, there is a quantity that we are
targeting. This is the *measure* part of success measures.
How to create success measures
For any success measure, you have to first create a baseline. A baseline
helps you understand the starting point to measure against.
The best baselines are based on real data. Let’s say we currently get
100 customer support calls a day. Reducing these calls by 50% would
mean we only get 50 calls a day. Measure the results on a monthly
basis against your baselines and targets.
While you shouldn’t expect to reach your target in the first month, you
should divide your target by the number of months in your project to
get a monthly reduction. If our project is 6 months, and we want to
reduce the number of support calls by 50%, we should see a reduction
of 8% per month.
Finishing Up
Setting your project up for success is a matter of understanding and
effectively communicating what you want to achieve. While creating
problem statements, goals, and success measures may feel like overkill,
the goal is to have a one page document that outlines, at a high level,
the justification and expected outcomes of the project.
This will help communicate to both project sponsors and the project
team members the problems we are trying to solve, the goals we are
trying to reach, and how we will know when we have reached them.
Exercise 1.1: Use this worksheet to create your problem statement
Description of the “ideal scenario”

Description of the current situation

Consequences of inaction

High level description of solution

Exercise 1.2: Use this worksheet to create your goals and success
measures
Problem Goal Success Measure(s)
Chapter 2: Users
At the end of this chapter you will know how to:
 Understand and create user types
 Refine and Prioritize Users
 Identify User Problems

Part 1: Understanding and Creating User Types

What is a User
“User” is user of your product. Simple, right? However, an issue that
makes it not so simple is that most software products have more than
one type of user. One of the biggest mistakes some product owners
make is in writing user stories as if there were only one kind of user.
Different users have different needs and wants. When all users are
lumped together, it makes it difficult to identify and prioritize the
needs.
Why Identifying User Types is Important
Organizing and prioritizing the features is made much easier once you
identify, organize, and prioritize your users.
An example of this is in enterprise accounting software. The day to day
users are most likely staff accountants and financial staff. However, the
real *customer*, who may not actually use the software on a daily
basis, is the CFO. The CFO is the real user is because he is the person
who has the ability to write a check to pay for the software.
As a result, more CFO-centric features, such as reporting, may be
prioritized higher than staff accountant-centric features, such as
automatic bank reconciliation. Identifying the user types helps us to be
able to organize and prioritize your features around our most important
users.
How to create a user type
Creating different user types is a 2 step process
 Brainstorm Users
 Organize Your Users
Brainstorming Users
To brainstorm users, meet with your team and your stakeholders and
have them write down different user roles on index cards or sticky
pads. This shouldn’t take long, and within 10 minutes you should have
plenty to choose from. This exercise has no rules or no turns. People
think, write, then toss the user role name into a bucket. Have your
team and stakeholders think up as many different user roles as they can
within the 10 minute time slot.
Organizing Users
After you have brainstormed your initial set of users, now is the time to
organize them. Take the pieces of paper and cluster them around users
that have overlap, such as Chief Accounting Officer and Controller, or
“accountant” and “staff accountant”. For each role that appears to be
the same, discuss with the group as to whether or not the role can be
combined.
Part 2: Refining and Prioritizing Users
Refining Users
Now that you have identified and organized your users, you will need to
refine them. You can do this by adding information to the role cards
answering a few questions about each user:
 How important the user is to the success or failure of the project
 How comfortable they are with computers and software
 How often they will use the software
 How expert they are at their job
 The user’s general goal
Prioritizing Users
We identify how important the user is to the success or failure of the
project so that we can appropriately prioritize their needs. If the CFO
needs robust reporting and will be the person signing off on the funds
to move forward with the project, either as an internal stakeholder or
external customer, we need to make sure we identify this up front.
Why Prioritize Users
Prioritization is important because no project ever has enough time,
money, or people. Priority will help us deliver the most value to our
most important customers as quickly as possible with the resources we
have available. In short, prioritizing users helps us prioritize features.
How to Prioritize Users
Prioritize users with a forced ranking of 1 to N, meaning no two users
will have the same priority. This will elicit discussion and give you an
outlet to think critically about which users are important and why.
Prepare for a controversial and vigorous discussion, but don’t be
dismayed. The controversy is part of everyone finding common
ground. This is to be expected, and it helps us deeply examine and
debate the importance of our different user types.

Part 3: Identifying User Problems

The user’s pain points take us to the next level of detail from the
problem statement we created in Chapter 1. If you find yourself in a
situation where the pain points for a particular user group have no
relation to the problem statement you identified up front, STOP.
 If this user group is important enough to create features for, then
we may need to revisit, or add to the problem statement.
 If this user group is not important enough to create features for,
because their problems don’t relate to our problem statement, it
may be that the features for this user group will either be low
priority, or out of scope altogether.
How to identify user problems
Now that you have brainstormed and consolidated your users, it is time
to identify the problems we would like to solve for the users, while
there are multiple ways to do this, we will go into detail on 3 in
particular.
 Open-ended single question questionnaires
 Open-ended time-boxed conversations
 Direct Observation
Open-ended Single Questions
An open-ended single question questionnaire uses a single, yet highly
combustible question to elicit feedback from the customer.
In the case of a project that will be creating a newer version of existing
software, an example of this is, “What is it that annoys you most about
how things currently work in the software?” You should expect a
laundry list of both major and minor annoyances to come from this
question.
Those annoyances might include things like, “Entering the
reconciliations usually takes 10 minutes to enter a full month of
reconciliations, but the page times out after 5 minutes and forces me to
relog in. When I relog in I have to start from the beginning. It would be
great if you could change that timeout or at least do some kind of
partial save so I can pick up where I left off.”
From this example, we can easily pick out a few pain points:
 Login timeout is too short
 If you time out, you have to start over
 There are no automatic partial saves
In the case of a project that will be creating a new software solution, an
example of this is, “What is the most annoying activity in your day to
day tasks?”
These annoyances might include things like, “Every week I get Fedex’d
paper expense reports from the field agents. We have 3 Accounting
clerks dedicated to that work. If we could find a way to allow the field
agents to enter their information directly into our system, we could
save a lot of money in postage, paper and printing costs, and 3
accounting clerks”
In this example, we can pick out a few pain points
 We spend too much money on postage costs associated with
expense reports
 We dedicate 3 FTEs to this effort
Any time there is an opportunity to automate what used to be a
manual process, it’s a win for all sides. For the product owner, there is
a tangible ROI to developing the feature. For the business stakeholder,
you are directly addressing a pain point with real dollars attached.
Next Steps: Create your open-ended single question based on the
above format. You can use google forms to get started free
(forms.google.com)
Open-ended Time Boxed Conversations
Open-ended time-boxed conversations are similar to their
questionnaire counterparts, with the advantage of face to face
conversation. Sometimes people are reluctant to type lots of
information into a form, but they will very willingly give you an earful.
Start with your same combustible question, then sit back, watch the
fireworks, and take good notes. As the conversation develops, you can
ask follow on questions to get more clarity.
Although face to face conversation is the best way to get information
from your audience, it is not as scalable or quick as a questionnaire.
Use the questionnaire along with group conversation and follow-on
questions for best results.
Next Steps: Set calendar invites for the people you want to interview.
Direct Observation
Another way to understand pain points is by watching someone do
their job. As they do their job, ask questions. Why do you do it that
way? Is there a better way? Doesn’t this get tiresome? Look for signs
of inefficiency: lots of copy-pasting from one form field to another,
large spreadsheets of information being kept on shared drives, body
language of frustration. Paper forms and information being keyed into
a database. Those all represent opportunities to make your user’s life
easier.
Next Steps: Set calendar invites for the people you want to observe.
Wrap Up
Often, developing a set of features for a product roadmap is like
planning a trip to a destination you have never been to, and only have a
vague idea of what it will look like when you arrive. Having a
systematic way to identify users and their problems will give much-
needed clarity to plotting that journey.
Exercise 2.1: Describe your users
User Description Priority

How important is the user to the success of the project?

How comfortable is the user with computers and technology?

How often will the user use the software?

How expert are they at their job?

What is the user’s general goal?

Chapter 3: Features
At the end of this chapter you will know how to:
 Understand Features
 Create a list of features that will solve your users’ problems
What is a Feature
A feature is a major unit of functionality created to solve a user’s
problem. Creating features and mapping them to user pain points
helps us understand how we are addressing users’ pain, helps us set up
a roadmap, and helps us prioritize our features.
Why Features Are Important
Features help us organize our problems and solutions into categories.
These categories will also help organize our user stories. Organizing
stories into features helps you trace stories to problems.
Understanding your problems, features, and stories helps you to
prioritize and sequence the order of stories based on which problems
are causing the most pain for your customers.
How to create a feature
You can create features using a 4 step process
 Identify the problem
 Brainstorm solutions
 Analyze solutions
 Pick a solution
The good news is you have already identified problems faced by your
users in the previous chapter, so the step of identifying the problem is
complete.
Brainstorm and Analyze
The next step is to brainstorm and analyze solutions to these problems.
Don’t do this in a vacuum. Have a group discussion with your team and
stakeholders to talk about the problems and get a list of potential
solutions.
Not all the solutions will be feasible. Some will have technical
constraints. Some will have business constraints. Some will have time
or money constraints, and some will be simply impossible. Still others
won’t be innovative enough.
An example of this is when Henry Ford popularized the car, he famously
stated, “If I had asked people what they wanted, they would have said
they wanted a faster horse.” Make sure you look for opportunities to
create solutions that are better than “a faster horse.” You will need to
balance the constraints cost, value, and feasibility to arrive at the best
solution. This is one of the primary jobs of an effective product owner:
to take a set of potential solutions to a problem and productize them to
create value for your customers.
Don’t fall into the trap of attempting to design features during the
brainstorming meeting. You will leave the implementation (the how)
for later. The purpose of this discussion is to create and pare down a
set of high level solutions to your customers’ problems.
Examples of features and problems
 Problem: Compounds in pharmaceutical database are hard to
spell and search
Feature: Search Usability Improvements

 Problem: Stock analysis charts need to be added to Powerpoint

presentations
Feature: Copyable, pastable, and exportable charts
 Problem: Field sales reps have to double enter data on tablet and
laptop in CRM
Feature: Cloud sync for contact data

 Problem: Real-time genetic analysis is not possible at the same

time as sequencing
Feature: Offline data analysis (dna sequencing solution)

 Problem: Need to retrieve a full data record just to edit a single

field
Feature: In-place edits (project management software)
Chapter 4: User Stories
At the end of this chapter you will know how to:
- Create user stories from your features
- Understand and create acceptance criteria for your user stories
- Organize your user stories according to features

What is a user story

A user story is a way to describe WHO wants WHAT and WHY. As
opposed to representing all the facts round this required functionality,
its primary purpose it to serve as a conversation starter so that the
people who will be implementing the functionality understand the full
context.
A user story is a convenient format for expressing the desired business
value for a feature told from the perspective of the person who wants
the feature, usually a user.

In scrum, user stories are one of the best and most popular form of
creating a shared understanding of what the user of a system wants to
accomplish
Parts of a user story
The user story consists of 3 parts
 Card
 Conversation
 Confirmation
The “card” is a high level description of what the user wants, usually
taking the form of “As a <type of user> I want <some functionality> so
that I can <achieve some kind of goal>” or the form I prefer “<type of
user> wants <functionality> so <reason>”
Since a user story is the promise of a future conversation, the
“conversation” part of the user story is just that; a conversation around
what the user wants and the goals the user wants to achieve.
The purpose of this conversation is to create a shared understanding of
the expected outcome of implementing the story.
The “confirmation” is the additional detail captured during the
“confirmation” that confirms the details, expected outcomes,
acceptance criteria, or anything else that was discussed and agreed
upon during the conversation
Story Details and Acceptance Criteria
A user story is not complete without acceptance criteria. Acceptance
criteria provide boundaries around the story so we know what specific
items we can verify against to ensure the story is done. Acceptance
criteria also provide a way to validate shared understanding exists
between the requester of the story and the implementer of the story.
Examples of user stories with Conversation Details and Acceptance
Criteria
Description: System administrator wants to select folders to be backed
up so the backup system does not save un-needed files
Conversation Details
- User should be able to select any folder in the system
- If there is a backup in progress, folder selection is locked
- Folder selection should be under “settings”
- Folder selection should be the standard windows directory tree view
- A folder that has been previously backed up then deselected will be
purged from the backup system
Acceptance Criteria
- Verify the user can select/deselect folders at will
- Verify the folder selection is locked when there is a backup in progress
- Verify the folder selection window is the standard windows directory
tree view with checkboxes
- Verify the unselected folders do not backup on the server
Mapping Stories to Features
Map stories to features by taking the feature and breaking it down into
one or many ways that feature could be implemented. Here are some
examples:
 Problem: Compounds in pharmaceutical database are hard to
spell and search
Feature: More intuitive search
o Compound technician wants autocomplete on searches so
he doesn’t have to spell out N-acetyl-p-aminophenol (generic name
for Tylenol)
o Compound technician wants the system to suggest
something close to what I type when I mistype N-acetyl-p-
aminophenol so I don’t have to spell it correctly to get to the search results

 Problem: Stock analysis charts need to be more portable

Feature: Copyable, pastable, and exportable charts
o Stock analyst wants to copy and paste charts from the
software to PowerPoint so he doesn’t have to re-create the
chart in PowerPoint from scratch
o Stock analyst wants “export to email” functionality so he can
easily email raw charts
 Problem: Field sales reps have to double enter data on tablet and
laptop in CRM
Feature: Cloud sync for contact data
o Field rep wants to enter data on phone and have it sync to
laptop so he does not have to enter data twice
o Field rep wants to enter data on laptop and have it sync to
phone so the most current data is available in the field

 Problem: Real-time genetic analysis is not possible at the same

time as sequencing
Feature: Offline data analysis (dna sequencing solution)
o Lab Tech wants faster sequencing, so she can run more
sequences in a shift
o Geneticist wants to run many combinations of analyses,
irrespective of analysis duration, so he can see which ones
have the most predictive strength

 Problem: Need to retrieve a full data record just to edit a single

field
Feature: In-place edits (project management software)
o Project Manager wants to edit a single field from within the
project view screen without having to bring up the project
edit screen so he will save time.
o Project Administrator wants to “bulk in-place edit” from the
project listing screen without needing to go to the edit
screen of every single project
Exercise 4.1. Use this template to create your user stories.
User Story
Description
Who

What

Why

Acceptance
Criteria

User Story
Description
Who

What

Why

Acceptance
Criteria
Exercise 3.1: Use this template to create your problem/feature pairs.
User Description Priority

User Problem Feature to Solve the Problem

Chapter 5: Sizing and Refinement
At the end of this chapter you will know how to:
- Work with developers to right-size user stories
- Split stories
- Combine stories
- Drive conversations to get more details into user stories
Estimation and sizing is one of the most controversial topics in
the Agile community. Some practitioners prefer a more
detailed approach, while others are not in favor of estimation in
any form. My approach is lightweight, yet pragmatic. I like to
use “threshold-based estimation”. If a user story is below the
threshold, I don’t waste time further estimating or
decomposing it. If the user story is above the threshold, I like
to work with my developer team to decompose it so that it’s
below the threshold. In this way, we can quickly map out a
large number of stories at the right level of detail.
To help guide me in my threshold based sizing, I use the rule of
1-2-3:
1 user story should take no more than
2 team members
3 days to finish
I don’t care who the two team members are, they can be a
front end and back end developer, a developer and a tester, a
designer and developer, a dba and a system admin, or
whatever combination the team would like to use. I like the
team to think about tackling stories in pairs of complementary
skills, rather than silo’d functional areas.
How to size your stories with developers
Step 1: Present your lean business case to give background
Step 2: Present the problem and feature area associated with
your first few user stories
Step 3: Present the user story, then ask, “Does the team
understand enough about this story to say that it meets the
rule of 1-2-3?” Continue the discussion until the team feels
comfortable with sizing. If the size is greater than 123, ask the
team, “What demonstrable subset of this story can I get that
fits under the 123 threshold?” Then have the team break apart
the story into demonstrable chunks that meet the rule of 123.
How to split stories that are too big
Sometimes the user stories are too big and the team has
trouble thinking beyond “horizontal splitting” (front end,
business rules, back end, database). Here are some patterns
for splitting stories:
 Workflow Steps
o User can create a policy directly
o User can create a policy to be held for legal review
 Business Rule Variations
o User can search for flights between 2 dates
o User can search for flights for “any weekend between
now and December”
 o User can search for flights +/- 3 days between
December 15 and December 20
 Major Effort
o User can pay with Paypal
o User can pay with Stripe integration
o User can pay with online check
 Simple/Complex
o User can search for flights with a maximum number
of stops
o User can search for flights with a maximum number
of stops and departing from SAN OR JWI
 Variations in Data
o User can search in English
o User can search in Spanish
 Data Entry Methods
o User can enter data in text field
o User can upload CSV
 Defer Performance
o User can get results within 5 seconds
o User can get results within 1 second
 Operations (CRUD)
o User can sign up for an account
o User can edit account settings
o User can delete account
If you have stories that are trivially small, I would recommend
combining them into a single “combo story” that falls below the
123 threshold.