According to Scrum Guide, the Product Backlog is defined as an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.
It further reads about the dynamics of this list of items – how it evolves through the time when market feedback and more knowledge are gained. The Product Backlog includes all kinds of items: features, functions, requirements, enhancements, and fixes. Together they are commonly referred to as Product Backlog Items or PBIs.
Many project management tools, like JIRA, offer a variety of different types of PBIs to be used when organizing work to be done. How many and which ones you use for the team, department, or the whole company greatly affect the nature of your work style. It can even contribute to defining the culture of the team and consequently the organization. There are implications if you use, say 12, issue types (as PBIs are called in JIRA) as opposed to only 4 or 5.
This topic is relevant to the introduction of the current implementation of the Backlog Health metric in Agile Tools Beta as the measurements you have to take as input for the metric are User Story oriented.
User Story is one of the PBI types. There are many others, like Task, Epic, Bug, Subtask, Improvement, Test, New Feature, the list can be (too) long. If you get carried away, it becomes a burden for the team and a source of disputes in an organization. At the end of the day – this (over)processing costs money.
Each PBI should have five attributes:
description,
order,
estimate,
value and
definition of done (DoD).
The DoD is a shared understanding of what it means for work to be complete and it usually boils down to a list of descriptive items that can be checked by the team and product owner when the PBI is, well, done.
For the sake of inputs (measurements) needed for Backlog Health, we have to define the Definition of Ready.
“Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning” -Scrum Guide
You will now be able to calculate the Story Points in Definition of Ready by inspecting the Product Backlog and go over all User Stories which are refined and estimated and add up the Story Points for each such User Story.
An Example of a very short Product Backlog with five User Stories, three of which are refined, can be “done” in one Sprint, hence are “Ready”:
To repeat – User Stories 1,2 and 4 from the above list were discussed by the team and have all the attributes: description, order, estimate, value, and definition of done written in some form which your organization or team has agreed upon. It can be a simple list with checkboxes or an elaborate set of Acceptance Criteria written in some domain language such as Gherkin.
For the example above, the number 15 is a sum of 2, 8, and 5.
Average Team Velocity is an implicit input gathered through dependent measurements on other metrics. It is calculated by providing Accepted Story Points with metrics such as Velocity History or Forecast Accuracy History.
By default, each metric will have a suggested frequency for providing measurements. In the case of Backlog Health, this is set to one week.
So, when doing the manual entry, it should take you no more than a few minutes to get the data, very simple and at the same time very powerful. An added value is actionable advice right below the gauge chart.
Based on market feedback we will make this metric more general or more configurable to cover not only the User Story based style of development. Try it out, feedback is appreciated.
Just a note on what features we are crafting at the moment – metrics editor and dashboard remake to lay foundations for a larger set of metrics that will cover all four key value areas and other categories of metrics, like product and organization ones. One of the future posts will cover which will be available – we would like to hear your voice (and vote) on which are more important to your organization.
Update: In early 2022, a product & company reboot has happened, which pivoted the product much more towards setting goals (OKRs) but still has its roots in teamwork, metrics, and evidence-based management. Also, note that a library of goals (objectives), key results, and metrics will be (is) available in the tool. A preview is here: https://www.agile-tools.io/metrics-library.