Tuesday, October 3, 2017

The Scrum Product Backlog | Supreme Agile

In traditional project management, the development team relay on a fully detailed SRS that determines the entire product specification prior to starting their work, in Agile, the product backlog is used to replace these requirements.  

The product backlog is a prioritized list of user stories, these stories are used to determine the work needed to be done by the team in order to deliver incremental releases of the product. In Agile, the product backlog does not contain the entire specifications needed to accomplish during the project (Why do we need to waste time in creating documentation that most likely will be changed in the future?), instead, the product backlog is used as a "Living Document" that changed based on the authority of the "Product Owner" during the project. 

Items in the Product Backlog

The product backlog contains a few mandatory items that we will use in order to determine the project effort and to increase visibility, A typical Scrum backlog will contain the following types of items:
  1. Epics, Features, User stories and Tasks.
  2. Functional Requirements.
  3. Non-Functional Requirements.
  4. List of Defects.

Each item may include the following attributes:
  • Work Estimations (Determined during the planning meeting)
  • The amount of value it adds to the project.
  • Description of the work needed to be done.
  • Acceptance and Definition of Done(DoD) criteria.
  • Priority Level (Order). 

The Hierarchy of the Product Backlog

There is a simple Hierarchy that we want to see in a product backlog (Especially if it's the first time you need to create it):

Epics -> User Stories->Tasks
I will create a specific article about Epics, but for now, let's use them as a "High-Level" user stories, these large stories are sometimes created without the full knowledge of what they will become (remember that we will not write the full requirements of the project) in the future.

Each epic may contain a large number of user stories that are used to achieve a larger goal driving from the targets we determine in the Epic story, during the project the team will refine the backlog to make it more precise and accurate for the team.

During the planning meetings, the user stories are divided into smaller containers of work called "Tasks", these tasks will determine all effort needed to be accomplished by the team in order to finish a user story (PBI), Examples:
  1. Need to make a research about the technology we will use.
  2. Need to design and created Automated tests.
  3. Need to define the architecture and Design of the new component.
  4. Need to integrate the new code into CI. 

1 comment:

  1. I would like to make a point about the accuracy of Task Estimation.

    I am an Agile Coach and was asked to spend a day with a large American Bank in London who kept over running Sprints (i.e. not meeting their estimations based on their general Velocity). It was costing vast amounts of money due to failures.

    Their problem was that, for example, they might have 2 stories - both with an estimation at User Story level of say - 3 (fibonacci scale), but when they broke the tasks down one might have a total estimate of (for example) 3 days and another 5.

    Once I pointed this out, they were able to get a better handle on estimating the correct number of Story Points during planning.


My Presentations