How can we define a good Backlog?

img_1079

A backlog is a very important asset for an Agile Team. It becomes even more important for a company who understands its value and is able to demand for high quality content and well organized backlogs.

Let’s try to understand what is a Backlog and all value behind this organized list of work by epics and stories shaping the product strategy.

A backlog can be defined by a list of requirements that, depending on the proximity to strategy or to implementation, can be written in Sagas, Epics, Stories or sub-tasks. This if we are in Scrum.

Independent

A backlog should be independent: development team, product owner, scrum master must be free to organize it and fulfill it with content, all of them must have the same common understanding about the content and they will manage it together but prioritization is always a product owner responsibility.

But if we are in a Product Organization, can a backlog be independent? Yes! When we mean independent is in a way that a Development team produces value for the product, in every sprint, considering the written requirements in the backlog. The team must agree with the stories ready to enter in the sprint, fulfilling the Definition of Ready. Saying that, the backlog is independent answering to “how to implement” but is dependent, contributing to accomplish the upper level requirements, reflecting company strategy.




Negotiable & Estimated

A backlog must be negotiable, and for that must have been estimated first. All team must know dependencies and the individual value contribution of each epic, feature or story for the release. Ultimately, the individual value contribution to the product.

Viable & Feasible

A backlog must be viable. Again, you should read the recommended post to understand the concepts negotiable and viable their are both connect with the MVP (Minimum Viable Product) and MPP (Minimum Possible Product) relation.

A backlog is viable if it’s feasible with in the target time to market.

Tested & Understandable in the customer language

A backlog must be tested. We should aim for include test tasks at all backlog levels, as part of the Definition of Done in each requirements level: Saga, Epic, Feature, story, task. A high quality product should reflect the efficiency of the team and deliverable.

A backlog should be understandable in the customer language. Assuming that the Product Owner expresses the customer wishes, he will be the clarification voice of each story in front of the Development Team.

The precondition for a good sprint planning is that the product owner must have the backlog prepared/ready and each story must have a definition of done and acceptance criteria.

Assumed premises before:

  • Having a high quality content in your backlog;
  • Refining regularly your backlog;
  • Having your backlog estimated and prioritized.

Benefits from a high quality backlog

You will have for sure benefits from a high quality content and well organized backlog:

  1. Clarity – around what to build and understand how each requirement maps to the product big picture. A backlog must give this clarity in a 360 perspective: to the team and outside the team.
  2. Accountability: Team must believe they are able to deliver, processes are working to make them deliver. They are accountable.
  3. Measurable progress – an estimated backlog, respecting ceremony’s cycles and repetition is the only way I know to measure the progress:
  • Backlog size
  • Velocity
  • Burn-down
  • Escaped Defects
  • Commit % Ratio
  • Acceptance % Ratio
  • Scope Change/Change requests




One Reply to “How can we define a good Backlog?”

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.