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 is 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 affects 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 introduction of current implementation of 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 organization. At the end of the day – this (over)processing costs money.
Each PBI should have five attributes:
- 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 very short Product Backlog with five User Stories, three of which are refined, can be “done” in one Sprint, hence are “Ready”:
|#||User Stories||Story Points|
|1||As a User I can press the Save button…||2|
|2||As a User I can change my email so that…||8|
|3||As a Power User I can disable alert notifications …|
|4||As a User I can click on a notification icon so that…||5|
|5||As a User I can click on a link in an invitation email so that…|
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 case of Backlog Health this is set to one week.
So, when doing 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 an 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 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 larger set of metrics that will cover all four key value areas and other categories of metrics, like product and organization ones. One of 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.