The Scrum framework : Product Backlog

The Scrum Framework

• The Scrum framework consists of Scrum Teams and their associated accountabilities, artifacts, events and rules as defined in the Scrum Guide.

The Scrum artifacts

• Artifacts represent work or value to provide Transparency and opportunities for Inspection and Adaptation.
• Artifacts are defined by Scrum and designed to maximize Transparency of key information so that everybody has the same understanding.

Scrum Artifacts

• Product backlog
• Sprint Backlog
• Increment

Product Backlog

• Product Backlog is composed by an ordered list of everything that is known to be needed in the product.
• Product Backlog is the single source of truth for the requirements and changes to the product.
• Product Backlog is dynamic, changing constantly with the product to be appropriate, competitive, and useful.
• Product Backlog exists only when a Product exists.
• Product Backlog is a list of all features, functions, requirements, enhancements, and fixes that constitute changes to the product for future release.

Product Goal

• The Product Goal is the commitment for the Product Backlog.
  • The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against.
  • The Product Goal is in the Product Backlog.
  • The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal.

Product Backlog composition

• The Product Backlog lists all that will change in the product for future releases.
  • Features
  • Functions
  • Requirements
  • Enhancements
  • Fixes
• Product Backlog changes
  • Changes in business requirements, market conditions, or technology may cause changes in the Product Backlog.
  • So Product Backlog is an ordered list of the work to be done in order to create, maintain, and sustain a product Managed by the Product Owner, reviewed and reordering as necessary.

Product Backlog ordering

• Product Owner (PO) is responsible for the Product Backlog, it’s content, availability, and ordering.

Product Backlog Items (PBI)

• PBI must be detailed as necessary :
  • Description
  • Estimate
  • Value
  • Order
• Higher ordered PBIs tend to be more clear and detailed than lower ordered ones.
  • PBIs that can be “Done” by the Developers within one Sprint are deemed “Ready” for selection in Sprint Planning.
  • Scrum does not mandate the use of User Stories.
    • Unless its mentioned in the Definition of Done (DoD), User Stories don’t need to be created or reported.

Product Backlog Items estimating

• Developers are responsible for all estimates for the PBIs.
• Product Owner may influence PBI estimates, but it is ultimately up to the Developers.

Product Backlog composition

• According to the Scrum Guide, the Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases.
  • It lists all the work that is deemed necessary for the product.

Product Backlog practice

• How Scrum Teams decide to capture this work is entirely up to them.
  • They can write User Stories, they can use a bunch of keywords, write use cases or even draw pictures.
• The Product Owner and the Developers both should work together.
  • The Product Owner is responsible for clarifying the Business confusion Developers might have about a Product Backlog item.
• The Product Owner keeps communicating with the stakeholders, creates new items in the Product Backlog, revises the order of items, answers questions, makes sure that everyone has the right understanding of items, and checks the completed items with the Development Team to ensure they are Done based on the Definition of Done (DoD).
  • The Product Owner is responsible for clearly expressing Product Backlog items to the Developers and making trade-offs.
  • The Product owner would thus know the requirements (business needs) of the Product backlog items.
• The Product Owner is responsible for ordering the items in the Product Backlog to best achieve goals and missions.
• Two or more Products can share a single Product Owner; however, he / she should be able to fulfill his / her duties.

Product Backlog Management

• The Product Backlog Management includes ensuring the Developers understand the items in the Product Backlog.
  • The Product Backlog Management requires the the items of the Product Backlog be ordered to best achieve goals/missions.
  • Clearly expressing Product Backlog items is part of the Product Backlog Management

Product Backlog Refinement

• The goal of Product Backlog refinement is to work with the Scrum Team and stakeholders (when relevant), to get Product Backlog items in a ‘ready state’.
  • Product Backlog Refinement is the activity in a Sprint through which the Product Owner and the Developers add granularity to the Product Backlog
  • Product Backlog refinement is all about removing uncertainty and creating common understanding.
  • Lack of knowledge is the starting point in refinement.
  • So, it is important to understand when using a Spike is appropriate or overkill.
• Product Backlog Refinement add detail, estimates, and order to items in the Product Backlog.
  • In Product Backlog refinement three types of uncertainty are discussed with the Developers:
    • Purpose uncertainty : Why do we need to build this?
    • End uncertainty : What do we need to build?
    • Means uncertainty : How can we build it?
• At the start of refinement, everything is unclear.
  • After refining a feature, all three types of uncertainty should be sufficiently clear to be able to estimate the feature.
  • If your team does not use estimates, you should be able to split the feature up in sprint-sized chunks.
• Sometimes everything is clear, except how to build a feature.
  • If the team has no idea how to build the feature, then the work cannot be accurately estimated.
  • It cannot be split up to fit in a single sprint either.
  • The risk of building a technical solution that is unfeasible increases.
• Who decides when/how Product Backlog refinement will occur?
  • Scrum Team

Feature

• A description of a business understandable and business valued piece of functionality.
  • The unit for prioritization, planning, estimation, and reporting.
  • Some agile methods use the term Story, or Prioritized requirement.

Product Backlog Refinement and Spike

• Now is the right moment to use a Spike :
  • When the team has no idea how to build a feature, then planning a Spike is appropriate.
  • Product Backlog Refinement explained

Product Backlog refinement practice

• Product Backlog refinement should consume no more than 10 percent of the capacity of the Developers.
  • Refinement includes Analyzing, Designing and Decomposing the Product Backlog items.
  • Programming and Testing does not happen during refinement.
  • It happens during the actual Sprint.
• PBIs with greater clarity and detail to tend to also have more precise estimates.
  • Why are PBIs for the upcoming Sprint refined ?
    • So that any one item can reasonably be “done” for the Sprint time-box.
  • What activities must occur in order to refine product backlog items?
    • Analysis
    • Design
    • Decomposition
  • Who should be present during Product Backlog refinement?
    • The c
    • The Product Owner
• Typically a Product Backlog item goes through three refinement meetings before it is considered to be in a ready state.
• Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog.
  • This is an ongoing process in which the Product Owner and the Developers collaborate on the details of Product Backlog items.
  • During Product Backlog refinement, items are reviewed and revised.
  • The Scrum Team decides how and when refinement is done.
  • Refinement usually consumes no more than 10% of the capacity of the Developers.
  • However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.
• During Product Backlog refinement, Items are expressed with more details and broken down to the smaller items that can be finished in a Sprint.
  • In addition, more effort will pay for refining Items on the top of the Product Backlog because they have more probability to implement in the upcoming Sprints so usually PBIs on the top of the Product Backlog are smaller than PBIs at the bottom of it.
• It could be argued that at least some Product Backlog refinement (PBR) is expected to take place with Stakeholders, but as a Product Owner (PO), your responsibility is to split the product vision into the product backlog items and have it ready for the development team to implement it.
  • The tough job isn’t it?
    • Product Backlog Refinement or PBR or Refinement or Grooming is the process of clarifying and estimating the backlog items.
    • The estimated backlog is the output of the PBR.
• How do we do refinement?
  • The refinement of a product backlog is iterative, progressive, and constant.
  • The first step is to define the product vision and understand the stakeholders
  • The second step is to identify the significant features of the product
  • The third step is to determine the detailed user stories
  • You will perform these three steps iteratively as follows:
    • The product vision you refine its maximum ones or twice a year
    • The significant features you groom them every program increment or every 2–3 months
    • and the items you look at them every Sprint
• Product Backlog Refinement is done by the Product Owner and the Developers collaboration.
  • It should not take more than 10% of the Developers capacity but the Product Owner should work on refinement without any constraint.
• There are many activities in Product Backlog Refinement as follows:
  • Breaking down the huge items (Epic)
  • Creating new items
  • Removing items
  • Adding detail to the items
  • Analysis
  • Design
  • Estimation
  • Valuation
  • Ordering
• In addition, breaking down the Product Backlog Items into sub-tasks are usually done in the Sprint Planning and even through the Sprint.
  • Doing it before selecting the Product Backlog Items for development is a type of resource waste.
• The Developers should participate in the Product Refinement as soon as possible and anytime during the Sprint.
  • The Developers should participate and understand the stories as soon as possible.
  • This can happen during the refinement phase.
  • They can start Decomposing them after Sprint Planning.
• The Product Owner and the Developers refine the Product Backlog items together.
• The Developers give input on Technical dependencies during refining a Product Backlog item.
  • During refinement, the Developers also clarify and expand on the intent of the Product backlog item, if needed.

Definition of Ready (DoR)

• Definition of Ready is a shared understanding by the Product Owner and the Developers regarding the preferred level of description of PBIs introduced at Sprint Planning.
  • Definition of Ready is not mandatory in the Scrum framework.

Artifacts

More informations for the Scrum PSD certification here.

Updated : 02/09/2021