What is Product Backlog and how product owners can manage it?

1. Product Backlog
More than To-Do list
@mahmoud_asadi

2. What is it?
The agile product backlog in Scrum is a prioritized features list,
containing short descriptions of all functionality desired in the
product.(read more)
You can find Product Backlog Example here.

3. Product Backlog
• Don’t try to gather all user requirement at beginning.
• At first, all PBI are large with few details. When PBI runs and through
conversation between stakeholders, PO and development team they
have been refined and convert to the smaller item with more details.
• Finally, each PBI is small with just enough details ready to move into
the sprint.

4. Product Backlog

5. Progressive Refinement
If PO try to keep all requirement's details at the same level:
• We must to have estimate all requirement's details at first of project
while our knowledge about project is minimum.
• we cost much time and energy to estimate requirements that maybe
never made in future.
• It produces large product backlog that refining it on future is not easy.
• We missed conversation chance because all requirements were
completed before.
So JUST IN TIME & JUST ENOUGH

6. What is User Story?
• A user story helps to create a simplified description of a requirement.
• It must be understandable by both business and technical people.
• It’s have simple structure and a placeholder for conversation.
• Read more here for more detail and examples.
• 3C:
• Card: As a … I want to … So that …
• Conversation: start conversation between stockholders, PO and development
team.
• Confirmation: conditions of satisfaction

7. The level of detail
• Epic: include many features (1 month or more)
• Feature: include stories (more than one sprint and less than one
month)
• Sprint-able Story: can done it in one sprint
• Task: usually assign to one or two team member and take time less
than 1 day to done. Describes how should done it instead why we
should done it.

8. INVEST – Good Quality PBI
A reminder of the characteristics of a good quality Product Backlog
Item.(Read more)
• Independent (of all others)
• Negotiable (not a specific contract for features)
• Valuable (or vertical)
• Estimable (to a good approximation)
• Small (so as to fit within an iteration)
• Testable (in principle, even if there isn't a test for it yet)
Useful article to find out how you can use or measure INVEST.

9. Special stories
• Non-functional requirements
Requirements that affect mostly story design and test. For example test all
front-end stories on all browser. You can set it as condition of done.
• Knowledge-Acquisition
There are sometimes that development team has not minimum required
knowledge to do stories. Measure cost of exploration and wrong decision.
Compare it and then make a decision that which on worth. (Fail-Fast strategy)
Note that a professional product owner prevent unlimited exploration.(read
about spike)

10. How to collect User Stories?
• User-Story-Writing Workshop
Brain storm to produce stories that presents product intended service. Held
with product owner, scrum master, development team and internal/external
stakeholders. Its take time many hours to many days. The target of meeting is
not to gather all user requirements. Meeting focus on a subject like users role
category. (Good practice)
• Story Map
A user story map arranges user stories into a useful model to help understand
the functionality of the system, identify holes and omissions in your backlog,
and effectively plan holistic releases that deliver value to users and business
with each release. (See more here)

11. Make the Product Backlog DEEP

12. Make the Product Backlog DEEP
• Detailed Appropriately. User stories on the product backlog that will be done
soon need to be sufficiently well understood that they can be completed in the
coming sprint. Stories that will not be developed for awhile should be described
with less detail.
• Estimated. The product backlog is more than a list of all work to be done; it is also
a useful planning tool. Because items further down the backlog are not as well
understood (yet), the estimates associated with them will be less precise than
estimates given items at the top.
• Emergent. A product backlog is not static. It will change over time. As more is
learned, user stories on the product backlog will be added, removed, or
reprioritized.
• Prioritized. The product backlog should be sorted with the most valuable items at
the top and the least valuable at the bottom. By always working in priority order,
the team is able to maximize the value of the product or system being developed.

13. Backlog Grooming
• What is it?
• Add PBI
• Complete PBI
• Estimate
• Ordering
• Prioritize
• By who?
• A joint and continuous activity, guided by product owner and stakeholders, scrum master and
development team effective participation. As general rule, development team help product
owner on backlog grooming in 10% of sprint.
• When?
• On release planning
• Once on each sprint
Some Useful links: link1, link2, link3, link4

14. Definition of Ready
• Having a Definition of Ready means that stories must be immediately
actionable. The Team must be able to determine what needs to be done and
the amount of work required to complete the User Story or PBI. The Team
must understand the "done" criteria and what tests will be performed to
demonstrate that the story is complete. "Ready" stories should be clear,
concise, and most importantly, actionable.
• Also read this article

15. Follow Management
• Release follow management
Split backlog with two lines that separate items to 3 category:
1. Must be on next release
2. We like to have it on next release but maybe can’t have it
3. Unnecessary items and we don’t want to have it on next release
• Sprint follow management
Always we must have ready PBI in top of backlog for 3 future sprint

16. Thank you
@mahmoud_asadi