PRODUCT

BACKLOG
EPICS, USER STORIES AND
TASKS
 Estimation and
prioritization of
Requirements, ideas, desires
user stories

Managed and
updated by
the PO
List of features that
product needs

Continuous
User story Evolution
 The Product Backlog is an ordered list of
everything that is known to be needed in
the product.

WHAT IS A It’s the single source of requirements for

any changes to be made to the product.
PRODUCT
BACKLOG It’s a prioritized features list,
containing short descriptions of all
? functionality desired in the product.

The Product Backlog is a dynamic list; it

constantly changes to identify what the
product needs to be appropriate,
competitive, and useful.
BACKLOG COMPOSITION

“As a shopper, I want to review “In the registration process,

items in my shopping cart before when you click on ‘Terms and
checking out so that I can see conditions’ – doesn’t lead anywhere”
what I've already selected” Features Bugs

“Make a research on various

JavaScript libraries and make a
“Upgrade all developers' Technica Knowledge selection for the most suitable
workstations to Windows 10” l acquisition one for our project”
work
CHARACTERISTICS OF A PRODUCT
BACKLOG
Very active document Product Backlog items The items at the top of
Product Backlog is
where all the wishlist and tend to be larger than the product backlog are
user requirements are never those on the Sprint on average smaller than
complete, but has just Backlog
gathered those at the bottom.
enough details

Product Owner orders items based on value, priority, Products have

dependencies and risk only one
Backlog
The product backlog acts as an input to the sprint backlog when comes to
functionality

As long as a product exists, it’s Product Backlog also exists.

HOW TO CREATE A PRODUCT BACKLOG -
START WITH THE TWO “R”-S
1
A team's roadmap and requirements provide the
foundation for the product backlog.
ROADMAP
To build a roadmap, product owners take into
account market trajectories, value propositions,
and engineering constraints – make a research.

REQUIREMEN Once these factors are reasonably well-

TS understood, they are expressed in a roadmap as
initiatives and timelines.
Take the information from
the roadmap and translate
that into tasks and work
items
3 Create EPICS in the Backlog – the biggest things that need to be done for
the platform. Add a few user stories for each epic.

4 Discuss with the team how user stories can be done. Ask for input from all
relevant parts of your organization (Marketing, Sales, Legal..)

5 Add more details for each user story. Craft stories from the point of view
of the user and include an action and a reason. (As a _, I want _, so that_.)
Think of all different users that will use the platform and define user stories
from their point of view.
6 Prioritize user stories according to what needs to be done first and order
items with the highest priority at the top of the backlog.

7 Add estimations to each user story and prepare for Sprint Planning.
WHAT MAY INFLUENCE A PRODUCT OWNER'S
PRIORITIZATION?

Customer priority

Urgency of getting feedback

Relative implementation difficulty

Dependencies between work items

TIPS TO PRIORITIZE YOUR PRODUCT
BACKLOG

Always follow
Arrange the top
Look at and re- the data, testing
items on your and user
prioritize your Keep the team
backlog to feedback
represent your backlog involved
regularly (input from
next sprint stakeholders)

If a task must Avoid

be done sooner, scheduling
make it more Backlog
detailed Refinement too
late or too early
in the process
WHAT DO DIFFERENT ROLES WANT FROM
THEIR BACKLOG?
The most appropriate structure
for your backlog will often end
up being a compromise that
satisfies varying needs of it’s
users.That’s because different
roles want different things from
the backlog.
As a team member, I want to know what user
stories to work on next with an understanding
of how my work fits into the overall matrix.
As a product owner, I want to see how
features are progressing so I can adjust and
refine priorities with the team.
As a stakeholder, I want to know when my
thing is ready.
PRODUCT
BACKLOG
STRUCTUR
E
• Epics are a collection of user stories, tasks, or bugs that
span across multiple sprints.

• An epic is a large story that cannot be simply achieved

in a single sprint. Usually, it takes months to
accomplish an epic. It typically refers
to a set of requirements that have not been
rationalized into user stories yet

• Epics are usually broad in scope, lacking in details,

and are meant to be split into multiple, smaller stories
before they can be worked on.
E-SHOP – EPICS EXAMPLES

• Product catalog viewing – for portraying categories of goods and list of goods in a given
category, filtering and searching for goods.
• Product selection – a selection of interesting products such as favorites, comparing, pricing
or add to a cart.
• The Cart of the products – browsing the content of a basket, comparing, counting the
total price.
• Payment – choice of payment options, total order, total price, shipping, payment itself and
payment confirmation.
• Product delivery – visual display of the delivery status, email and SMS notifications.
CREATING • Reporting — Create epics for the projects that
AN AGILE managers and executives will want to keep an eye on.

EPIC • Storytelling — Use epics, and the stories that roll up

into them, as a mechanism to tell the story of how
you arrived at the current state of a feature or
product.

• Culture — Let organizational culture dictate the size

and granularity of an epic.

• Time — Most development teams rely on estimation

frameworks instead of time, but it’s a worthwhile gut
check to make sure your epics will take a couple
weeks to complete. Not too long and not too short.
 • User role or persona — Create a unique story for
each user persona. “Quicker login for new visitors,”
“quicker login for return customers,” etc.

• Ordered steps — Break down the process and

BREAK DOWN AN create a story for each step.
AGILE EPIC • Culture — Let team norms dictate if a story is a quick
task or a week-long project.

• Time — Barring another agreed-upon convention,

design stories that can be completed in one sprint or
less.
The user story describes the type of user, what they want and why. A user story helps to create a simplified
description of a requirement.

Task

Epic
User Story

Task

Product

User Story Task

Task
Epic

User Story
Task

Task

As a frequent flyer, I want to

use my flight points, so that I
can upgrade to upper class
USER A user story represents a small piece of business value
STORY that a team can deliver in an iteration.

It contains just enough information to give the Scrum

team proper context as to what the final product should
be like, and for them to calculate an estimation for the completion

• Template for writing a user story:

As a < type of user >, I want < some goal > so that

< some reason >.

 INVEST ACRONYM (BILL WAKE)
SET OF RULES USED IN CREATING WELL-FORMED USER STORIES

Independent Negotiable
Valuable

Estimatable Small
Testable
WHY USE USER
STORIES?

• Keep yourself expressing business value

• Avoid introducing detail too early that

would prevent design options and
inappropriately lock developers into one
solution

• Avoid the appearance of false

completeness and clarity

• Get to small enough chunks that invite

negotiation and movement in the backlog
 • As a shop owner, I want to customize the e-shop, so that I can promote my
business at the best way possible.

• As a network supplier, I want to view usage by the store, so that I can bill shop
EXAMPLES owners.
• As a user, I want to migrate all my data backup in a cloud system
OF USER to free up my device.
STORIES • As a System Admin, I want to be able to configure user settings, so I can
control access.

• As a consumer, I want to scan the bar code with my phone, so that I can
compare and find the lowest price of the same product in various stores.
NON-FUNCTIONAL REQUIREMENTS AS
USER STORIES
Non-functional requirements
are requirements that are not
about specific functionality
but are rather about an
attribute or characteristic
of the system.
Examples include reliability,
availability, portability,
scalability, usability,
maintainability.
Not all non-functional
requirements end in “-ility.”
We also have security,
performance, robustness
and so on.
 • As a customer, I want to be able to run your product
on Windows and Macintosh.

• As a user, I want the site to be available 99.999 percent

of the time I try to access it, so that I don't get
EXAMPLES OF
frustrated and find another site to use.
NON-FUNCTIONAL
USER STORIES • As someone who in the Balkans, I want any of the Balkan
languages to be included in the app.

• As a user, I want when I open the app, to be loaded below 5

seconds
The technical work that a development team performs in order to complete a product backlog item.
Most tasks are defined to be small, representing no more than a few hours to a day or so of work.

Task

Epic
User Story

Task

Product

User Story Task

Task

Epic

User Story
Task

Task

Implement the
design for Login
TASK • Scrum tasks are detailed pieces of work that are
necessary to complete a story. Tasks can range from a
few hours to several hours and are assigned to team
members who have the skills or expertise to do them.

• Tasks are the smallest unit used in Scrum to track

work. A task should be completed by one person on
the team, though the team may choose to pair up
when doing the work.

• Breaking the user story down into tasks helps the

team determine how they'll approach the story. By
getting into this level of detail, any unknowns will be uncovered.
EPICS, USER STORIES,TASKS -
SUMMARY
• Learning how to write epics, stories and tasks is
essential. Basically, these three are the
foundations of a sprint, giving your agile team
a crystal-clear picture of what needs to be
done, who needs to do it, and why it should
be done.
• Though there's plenty of scrum literature that
give recommendations and best practices
associated with estimates, user stories, and task
creation, the terms "user story" and "task" don't • What can be delivered in the Increment resulting from the upcoming
appear in the Scrum Guide by
Ken Schwaber and Jeff Sutherland.
Scrum Guide
The work to be performed in the Sprint is planned at the Sprint Planning.
This plan is created by the collaborative work of the entire Scrum Team.
Sprint Planning is time-boxed to a maximum of eight hours for a
one-month Sprint. For shorter Sprints, the event is usually shorter.
The Scrum Master ensures that the event takes place and that attendants
understand its
purpose.The Scrum Master teaches the Scrum Team to keep it within the
time-box. Sprint Planning answers the following:
Sprint?
• How will the work needed to deliver the Increment be achieved?
USER STORIES
EXERCISE TIME
 • Complement your Product Backlog with
Complement
a Product Roadmap

• Focus your Backlog on the Next Major

Release
Focus TIPS FOR
• Start with a Short and Sketchy Product WORKING
Backlog EFFECTIVEL
Start
Y WITH A
• Collaborate with the Development Team PRODUCT
Collaborate
BACKLOG
• Say No
Say No
Look • Look beyond User Stories
● Prioritise your Backlog

Manag
e
• Proactively Manage your Product Backlog
• Get the Backlog Ready
Get

• Make your Product Backlog Visible and Easily

Make
Accessible
 PRODUCT BACKLOG - SPRINT
BACKLOG
The Product The Sprint
Backlog is an Backlog is the
ordered list of set of PBIs
everything that selected for the
might be needed Sprint, plus a
in the product plan, often a
and is the single list of tasks, for
source of delivering the
requirements for Product
the Increment and
product. realizing the
Sprint goal.
 Covers all tasks to
achieve sprint goal

Sprint Backlog

Only modifieable
by the Dev. team

Product Backlog Created by whole team

SPRINT • Set of Product Backlog items selected for the sprint plus a
plan for delivering the product increment and realizing the
BACKLO sprint goal
• Sprint Backlog is highly visible, real time picture of the work
G the development team plans to accomplish during the sprint.
• The sprint backlog is unchanged during the period of the
sprint. It can be changed, but only during the sprint planning
meeting.
• All Sprint Backlog items are OWNED by the Development
team.
• Sprint Goal is crafted by the whole Scrum Team during
Sprint Planning. Sprint Backlog is a plan for achieving the
Sprint Goal.
• If there are items left unfinished by the end of the sprint,
they will be added back to the product backlog and
addressed during the next sprint.
 The Sprint Board lets you visualize all the work in every sprint, so everyone can see the progress for each task

User Story

Tasks

Bugs
SPRINT BOARD

The Scrum Board serves as a very useful

visual tool that lets your agile team easily
keep track of the sprint.

The board should be updated on a daily

basis.

Sprint Board helps the team sustain

momentum but also gives a clear idea to
the Product Owner of where they are at in
a particular sprint (whether the team is
lagging behind or is just on time) and make
adjustments if necessary.
 • Planning Poker in Scrum brings together multiple
expert opinions for the agile estimation of a project.
This type of agile planning includes everyone:
programmers, testers, database engineers, analysts, user
interaction designers, and all other persons involved in
PLANNING the project. Because these team members represent all
POKER disciplines on a software project, they are best suited
for the estimation task.
 The estimators discuss the feature and, if needed,
ask the product owner questions. When the estimators have
finished their discussion, they each
select one card privately to represent his or her
estimate. The cards are then revealed
simultaneously.

RULES OF If the estimators select the same value, that number

becomes the estimate. If their values differ, the
PLANNING estimators discuss their rational.Those who chose
the highest or lowest value should share their
reasoning with the group before each estimator
POKER selects another estimate card, repeating the
process.

The estimators continue the poker planning process

until a consensus on the value is achieved. If they
cannot agree, the estimators may opt to defer the
agile estimating and planning of a particular item,
pending additional information.
TIPS FOR SCRUM PLANNING
POKER

When to play: Typically,

Break out into smaller estimating teams need
Keep discussions sessions: It is ideal, to play planning poker
productive: A two- whenever possible, to on two different
minute sand timer is a break a larger group occasions: during the
helpful tool used to down into smaller sub- first iterations before
teach teams how to teams; often occurring the project begins and
estimate more rapidly. at the start of a new when new stories are
project. identified during an
ongoing iteration.
TOP 3 REASONS WHY PLANNING POKER IS
GREAT

1 2 3
It fosters It uses consensus Through discussion
collaboration by estimates rather of each user story,
engaging the entire than single person it exposes issues
team. estimates. early in the project.
ESTIMATIONS: STORY POINTS VS
HOURS
STORY POINT
unit of measure for expressing an
estimate of the overall effort that will be
required to fully implement a product
backlog item or any other piece of work.
Stable index that’s independent of the
skill or experience of team members,
lets you track a team’s velocity, and
helps you stay flexible in re-planning
project release dates.
MAN – HOUR
amount of work that can be
completed by one person within one
hour
Some tasks are difficult to estimate precisely.
If one developer estimates a project but
another completes the task, the estimate
becomes invalid. People generally
underestimate obstacles they might face and
consider only the best-case scenario.
STORY • When we estimate with story points, we assign a
POINT point value to each item. We should use relative
values. A story that is assigned a 2 should be twice as
S much as a story that is assigned a 1. It should also be
two-thirds of a story that is estimated as 3 story
points.
• What Goes Into a Story Point?

1. The amount of work to do

2. The complexity of the work

3. Any risk or uncertainty in doing the work

FIBONACCI SEQUENCE FOR STORY POINTS

• The fibonacci sequence is used by Scrum teams for story point estimates – 1, 2, 3, 5, 8, 13,
21, and so on.Teams use this sequence, rather than a linear 1 – 10 as it forces them to
provide a relative estimate. Easier to ask ‘is that a 5 or an 8?’ than ‘is that a 6 or a 7?

• This method is characterized by the fact that every number after the first two is the sum
of the two preceding ones.

• For E.g when we say a story has 2 story points another one has 4, it implies that the
second story will require twice as much effort as the first.
EXAMPLE WITH STORY POINTS

Our company has a project at 200 SP. One developer starts working on it. His velocity is 1 SP per 3 hours.The start date is May 30th. Based on this
information, it’s easy to calculate the project release date.

• The time needed to finish all the work:

T = Qsp*t,
where Qsp is the general quantity of SP in the project and t is the time to complete 1 SP.
200x3 = 600 (hours).

The number of workdays

Nw=T/Prt,
where Nw is number of workdays,T is the time needed to finish all the work, and Prt is the quantity of productive hours in the working day (usually 6 hours)
600 / 6 = 100 (workdays).

Having a calendar at hand, we can then calculate a release date — October 14th.

If for some reasons we change the developer and the new developer works with the velocity of 1 SP per 1.5 hours, then we can quickly re-calculate our date.
Now the number of workdays required is 50 and our date of release will be August 5th.
VELOCIT 1) Velocity is a measure of how fast a team is going
(simple definition)
Y 2) Velocity is an extremely simple, powerful method for
accurately measuring the rate at
which Scrum development teams consistently deliver
business value.
3) Velocity measures how much functionality a team
delivers in a sprint.
4) Velocity measures a team's ability to turns ideas into
new functionality in a sprint.

• It’s generally an accurate prediction, even though rarely a

precise one.
VELOCIT
Y
• After a few Sprints the velocity of a Scrum Team
will most likely be predictable and would allow quite
accurate estimation about the time needed until all
entries in the Scrum Product Backlog will be
completed.
• If the velocity of a Scrum Team is e.g. 30 story
points and the total amount of remaining work is 155,
we can predict that we need about 6 Sprint to
complete all stories in the Backlog
BUT.
In reality the entries in the Scrum Product Backlog will
change over the duration of the project. New stories
are added and other stories are changed or even
deleted.
VELOCITY - USE CASE

• You and your team are preparing for the first sprint of development. You
want to calculate an estimated velocity in story points, but your team
has never worked together.

• You have planned to complete 4 user stories this sprint.

- User story A has been assigned 3 story points.

- User stories B and C have both been assigned 5 story points each

- User story D has been assigned 1 story point.

• You broke down the user stories into tasks and created task time
estimates.You have estimated that these stories will take 110 hours to
complete in total.Your development team has only 95 available hours
this sprint.You decide to remove user story A from the sprint because it
was estimated to take 15 hours.What would be your team's estimated
velocity for Sprint 1?
WHAT WOULD BE YOUR TEAM'S
ESTIMATED VELOCITY FOR SPRINT 1?
A. 3 user stories.

B. 14 story points.

C. 11 story points.

D. 110 hours.

E. 95 hours.
WHAT WOULD BE YOUR TEAM'S
ESTIMATED VELOCITY FOR SPRINT 1?
A. 3 user stories.

B. 14 story points.

C. 11 story points.

D. 110 hours.

E. 95 hours.
SOLUTION

• Velocity estimates should be based on the size measurement used for user stories. In this
example we use story points.This makes answers A, D, and E incorrect since they are
measured by user stories or hours.
• You decided to remove user story A after you determined that based on your task estimates.
Your team does not have time to complete that user story.Therefore, your velocity estimate
would be based on the sum of the story points for user stories B, C, and D.
• This is 11 story points, therefore C is the correct answer. A team's actual velocity
achieved in each sprint may fluctuate for various reasons.Your team's first sprint may have a
lower velocity than other sprints.This could occur if the team is still learning how to
collaborate with each other or if they are learning new technologies.
BURN • The Scrum Burndown Chart is a visual
DOWN measurement tool that shows the completed work
per day against the projected rate of completion for
CHART the current project release.

• Purpose: to enable that the project is on track to

deliver the expected solution within the desired
schedule.
BURN DOWN CHART

• At the start point the actual work

remaining is the same as the ideal
work remaining but as time
progresses the actual work line
fluctuates above an below the ideal
line depending on this disparity
between estimates and how effective
the team is.
MEASURING
PERFORMANCE
If the actual work line is
above the ideal work line
it means that there is more
work left than originally
predicted and the project is
behind schedule.
If the actual work line is
below the ideal work
line, it means that there is
less work left than originally
predicted and the project is
ahead of schedule.
BURN-DOWN CHART
USE CASE

• Your development team is about to

start their sixth and final sprint.
This is the release burndown chart
for the project.
HOW MANY STORY POINTS HAS YOUR TEAM COMPLETED,AND HOW
MANY DO THEY HAVE REMAINING?

A. 100 story points completed, 15

story points remaining.

B. 100 story points completed, zero

story points remaining.

C. 85 story points completed, 15

story points remaining.

D. 85 story points completed, zero

story points remaining.
HOW MANY STORY POINTS HAS YOUR TEAM COMPLETED,AND HOW
MANY DO THEY HAVE REMAINING?

A. 100 story points completed, 15

story points remaining.

B. 100 story points completed, zero

story points remaining.

C. 85 story points completed, 15

story points remaining.

D. 85 story points completed, zero

story points remaining.
SOLUTION

• In this project, there were 100 total story

points, we know this because there were
100 story points at the beginning of sprint
one. At the beginning of sprint six, which
is the last sprint of the project, there are 15
story points remaining.
• Since, we started with 100 story points
and have 15 remaining, that means that the
team has completed 85 story points.
THANK YOU FOR YOUR ATTENTION!