Product Backlog Building Canvas

3Ws of User Story

User Story is a textual format for the concise description of a
requirement, which seeks to answer three specific questions from the
acronym known as 3Ws: Who? What? and Why?

• Who is it for?
• What is the action or activity the person accomplishes with it?
• Why will the person use it (benefit or reason)?

INVEST

In the book Extreme Programming Explored, William C. Wake shared the
acronym INVEST, where each letter represents one of the six important
characteristics of a User Story:

• Independent: One story does not depend on another.
• Negotiable: A story captures the essence of what is desired. It is not
  a fixed contract. Conversations and negotiation are welcome.
• Valuable: A story clearly describes customer or user value.
• Estimable: A story provides enough information for the development
  team to estimate it.
• Small: A story should be relatively small in size to complete in
  the shortest possible time and fit into an iteration (Sprint),
  considering the context of the team.
• Testable: A story must be clear enough that tests can be defined for
  it.

A few years after this creation, Mike Cohn ended up renaming the
letter S, from small, to sized appropriately, as some people created
stories a little bigger, but suited to their context.

3Cs Model

Card: The User Story description must fit on an index card, containing
enough to identify the User Story. The most common format is:

Here is an example:

“As a participant, I want to register for an event so that I can attend it.”

Conversation: A User Story description should fit in an index card.
The main reason is that there isn’t much room to write, which forces the
written description to be brief. Therefore, a lot
of conversation is needed to clarify doubts and detail the work needed to
implement it. Working with User Stories means accepting that
conversations about work will be ongoing, and not just placed at the
beginning when the requirement is initially set. The best documents help
people remember conversations, not replace them.

Confirmation: This is where you determine if the User Story goal is
achieved. To do this, the acceptance criteria confirms that the User
Story has been implemented correctly and successfully delivered.
Acceptance criteria must be defined for each story before the team starts
implementing it. That way, there are no surprises when checking the
completion and verifying the outcomes.

Describe the persona

A persona represents a user of the product, and so a description should speak
not only of the person’s role, but also their needs and goals. This creates a
realistic representation of the user, helping the team to describe features
from the point of view of who will use the product.

Describe the main personas from questions such as: “What is this person’s profile?
What does this person do? What does this person expect?”

Figure 2: Persona block example

Currently, it is relatively common to find discovery workshops, inceptions,
and other activities that generate artifacts and knowledge about the personas
– such as, for example, the empathy map. If this is the case, share the previously
constructed material. But remember that, at the time of PBB, the focus is on the
profile of the personas and their activities, which are necessary points for the next step.

Understand the Features

With a good understanding of the persona and their activities,
it’s time to analyze each one of
them, reread them, and look for actions or interactions of the personas with the product,
so that you can represent each of these interactions as a feature.

Figure 3: from persona to feature

Describe the features from a answering the following questions: the user is trying to
do something, so the product must have a feature for that. What is it? What persona issues
does this feature solve? What benefits does it bring to the persona?

Figure 4: Feature block example

Write the feature description on one big post-it, then write down the challenges and benefits
on smaller post-Its and place them next to the post-It, describing the feature.

Features are generally described at a higher level than the work items
that will appear in a development plan. Before starting
to develop a feature, it must be analyzed and its work items must be described and quantified.
In PBB Canvas, you first identify, understand, and prioritize the features, then detail them in
product backlog items.

Identify the PBIs

Product Backlog Items (PBIs) are elements that make up the product backlog. They reflect the
development work needed to improve the product and to meet customer or stakeholder needs.
In the previous step, you described the features along with their challenges and benefits.
Now it becomes necessary to break these down further to allow for smaller, more accurate items.
These are called PBIs.

To identify the respective PBIs in the product backlog, ask participants to answer the following
questions: “What is the first work item (or step) for this feature? And the second? And the next ones?”

Figure 5: Product Backlog Item block example

Each PBI must represent an action performed by a user on the product. For example: 1) “Buy a book” and
2) “Add a speaker to the conference.” These actions are described in textual form to provide context
and uniquely identify the item.

Connect the blocks as a User Story

The Product Backlog Items form the basis for the list of User
Stories. You take each PBI and use the persona and features to flesh
out the typical User Story template. The figure below shows an example
of this.

Figure 6: Writing User Story with PBB

• You fill the as a section, the who, of the story with the persona
  profile, written on a post-it on the Persona block of the PBB canvas.
  In the case it is ´speaker´.
• You fill the I want to section, the action, with the post-it on the Product Backlog Items block of the PBB canvas.
  It represents one of the steps for building the Publish work feature.
  For this story it’s ´perform the publication of work´
• You fill the so that section, the benefit, with one of the post-its next to the Publish work feature. It represents one of the
  benefits of the feature, here ´make content available´

So the final story reads:

After writing the core elements of the User Story, it is time to fill it up with the extra information on Acceptance criteria,
tasks, User Interface, and enablers (if any). You can do it in the Product Backlog Items area of your PBB
canvas, or start documenting it on your tool of preference for recording User Stories.

User Story example

Below you find some details about the description of three
features for the Talks Collection digital product with some User Stories, acceptance criteria, tasks and
interface:

Following are the three sample features with their respective
personas and User Stories.

Acceptance Criteria

The acceptance criteria are intended to describe how to validate a User
Story. In doing so, acceptance criteria provide a checklist that determines when a User Story
is done, complete, and working. Below is a sample User Story from the
Product Backlog Building book:

“As an account holder, I want to withdraw money at the ATM to avoid
the bank line”.

Here is a possible acceptance criteria for this context:

• The account holder with sufficient balance is able to withdraw money
  from her account.
• The account holder without sufficient balance is unable to withdraw
  money from her account.
• The account holder with sufficient balance cannot withdraw money from
  her account if the ATM does not have enough money to withdraw.

The format presented is compared to a checklist used to verify that
the story is complete and working, that is, if it passes through all the
acceptance criteria.

Breaking User Stories into tasks

It is very common to break a User Story into even smaller pieces about
the work that must be done, by stating, “these are the tasks.” By listing
the tasks needed to build a story, the development team goes into
technical details about how the smaller pieces will be implemented.
Unlike stories, tasks do not follow a defined textual format. They are
more direct, with a very technical language, from the development team to
the development team.

A task identifies something that needs to be done, something necessary
for a story. As such, the task will not necessarily be self-contained and
will not demonstrate business value. Most of them tend to be for
programmers, described in terms used by them. Some examples of tasks are,
change input table fields, create test accounts for users, and automate
data generation scripts.

User interface

Not every work item is associated with an interface. But for items
that will be associated with some user interface (or UI), you need to
clarify that association in the context of the User Story.

An interface can be described in a few ways: sketch (or simple
drawings on paper), wireframe, mockup, or prototype. The way to describe
it varies from team to team, depending on the team culture and the time
spent to detail it.

A question that arises is how much of the interface needs to be defined to
start working on the story? The answer is basically the team’s agreement to
decide if the story is ready from a UI point of view. The most important thing
is that the group is aligned and comfortable with the work to be done.

Enabler

Sometimes writing a specific story can be difficult. As much as you try
to use the INVEST and 3Ws techniques as guides, for some cases, you still
can’t write it satisfactorily. If this happens, try to see if you are
dealing with one of these two cases:

1. The story relies on some previous study; or
2. The story relies on something very technical that takes
   considerable effort.

In both cases, you can either create a bigger story and consider this
a part of it, or you can break it down into something apart: an enabler.
This “something apart” is called the enabler because it is not adhered to
the story format. It is a work item needed to enable another story.

Example of a filled-out user story

Now, check out an example of a story the “publish talk” feature of
Talks Collection. It provides a full example of a User Story with acceptance criteria,
tasks, Ui and enablers.

User Story 1.1

As a speaker, I want to link the external presentation in
order to integrate talks.

Acceptance Criteria 1

Scenario 1: Link presentation across presentation sharing platform

Given that there is a valid link on the SlideShare platform

When I associate the external presentation link

Then It will show a preview of the presentation on the screen

Acceptance Criteria 2

Scenario 2: Associate presentation when publishing talks

Given that the presentation link is valid

When I publish the talk

Then it will show the associated presentation in the published talk details

Tasks:

• Consume the presentation endpoint.
• Create a UI to show a PDF file of the presentation.
• Create logic in the backend to link presentation with published talk.
• Change parameter to public or private link.
• Create test data to verify that the link is valid.
• Change DB to include the presentation link.

Interface Sketch

Exploratory Enabler:

Study endpoint API integration with online presentation
sharing platforms (SlideShare and Speaker Deck).

Technical Enabler:

Consume the oEmbed endpoint as a link tag in the header
so it can be automatically detected when embedding the
presentation.

Definition of Ready

The Definition of Ready (DoR) is the agreement between the team that
indicates when a PBI is ready to be pulled into a Sprint, that is, when
it has enough information to go into planning, execution, and delivery.
People often say, “This item is ready to start work”, and generally this
indicates that the team:

1. Has the necessary information to work on the item.
2. Understands the reason for the item.
3. Can demonstrate the completion of the item.
4. Identifies how the item composes/relates to a feature.
5. Agrees that the item fits in a Sprint, or the designated time frame.

In relation to each PBI candidate for the next Sprint (or iteration of
work), the team checks the PBI Ready Checklist:

This list is an example of a checklist for DoR. Generally, teams define
and maintain their checklists, which demonstrate their preferences in
preparing the work.

Refinement of the product backlog must be continuous. The team will be
continuously working on the next candidate items, preparing them for the
next Sprint or work interaction. The use of the ready definition and the
done definition is not limited to Scrum alone; it is also a very useful
practice when working with Kanban and other agile methods.

Definition of Done

Definition of Done (DoD) is the agreement that demonstrates the
quality of the PBI produced, in which “done” confirms everyone’s
satisfaction with the work performed.

DoD clarifies the understanding of the work completed as part of the
product increment. The moment a PBI meets the definition of done, it
means that the increment is ready to be released into the product.

If a PBI does not meet the DoD, it should not be released or even
featured in the Sprint Review. It must remain a work in progress (WIP)
for the team.

For each PBI considered done, the team demonstrates that the item:

This list is an example checklist for the DoD. Teams define and
maintain checklists, which demonstrate their preferences in job
verification.

You can download these sample DoR and DoD checklists as extra
resources from the Product Backlog Building here.