Product Backlog

Why

Transparency and focus is what the Product Backlog brings. It is the only place where the work for the product (and team) is listed, prioritized by the Product Owner. This makes it very clear to everyone involved what the focus of the team will be in the upcoming sprints. Also, within the backlog the status of user story is managed.

Prepare for success

Make sure that there are sufficient actionable user stories (and/or bugs) at the top of the product backlog for the upcoming sprint. If not, plan a co-preparation session to turn an epic into user stories, or plan extra time for backlog refinement.

How

The product owner manages the product backlog. The top of the product backlog should contain the most valuable user stories. Stakeholders and team can give their input for this, but the Product Owner has the final say about the order of the user stories.

For this, the product owner:

  • Interacts with end users and other stakeholders throughout the project
  • Reviews the business case and goals towards the current product status.
  • Organizes co-preparation sessions for new epics
  • Works with the development team to refine the backlog (preparing for upcoming sprints)
  • The preferred tool for managing and documenting the Product Backlog at Kabisa is Pivotal Tracker (PT). In PT, new features start as User Stories in the Icebox column, and can be linked to an Epic. User Stories will transfer to the Backlog column in PT when they are valuable for the product (usually just before or during Backlog Refinement). During Sprint Planning, the stories can be taken into the Sprint, called “Current Iteration” in PT. The development workflow is easy to follow within PT, including Accept of Reject by the Product Owner. When the sprint is finished, the entire iteration (including its accepted stories) move to the Done column. This way, PT is also the historic documentation of function of the product.

Definition of Done

As long as the product development is ongoing, the product backlog is alive. The Pivotal Tracker board contains the delivered, planned and future user stories.

Real Life Example

A startup company came to Kabisa with a limited budget to develop an onboarding app. The product vision included an app for new employees that should be highly customizable per company, per department and per new employee. The customization would be done via a custom CMS that included various level of authorization for different departments and roles within the companies. On the product backlog, all user stories that would make the CMS better than what was minimally required, got a lower priority than the user stories that would make the app richer and nicer. A better app would give more business value than a better CMS, because for the CMS there was always the alternative to let that work be handled by employees of the startup company, instead of by their customers employees. This way, we were able to deliver a great customizable app for this startup within the limited budget. They will have to do quite some CMS work themselves to support their first customers, and once they make some profit, they can invest that in further developing the CMS.