When is a Backlog Not a Backlog?

It is interesting how language evolves and how ‘normal’ words (like backlog) can take on whole new connotations with the advent of different business practices. Take words like agile and lean. These words, in their own context, now reflect particular mindsets, principles, practices and behaviours; they are no longer mere adjectives but demand a specific understanding and knowledge of associated methods.

Consider a conversation overheard the other day, when someone (not in a lean or agile context) made the comment: ‘There’s a whole backlog of work we need to get through before that’ which, in effect, was politely saying “Take a ticket and get in the queue”. There was a pause, and then: “Oh, I wasn’t meaning the agile-type of backlog – maybe I should use a different word?”

So when is a Backlog not a Backlog?

The term backlog in a conventional setting can at times have a negative connotation such as the notion of an accumulation of unfinished work. And what you are really thinking is: Do we have to get through all of that sometime soon?

Switch now to the maybe ‘enlightened’ agile usage of backlog as in Product Backlog, Sprint Backlog, Project Backlog, or even the DSDM variety of Prioritised Requirements List (PRL). Now we are talking! In an agile sense that is what a backlog really is (and should be): prioritised.

Did you realise that the Project Management Institute (PMI)® even define backlog in the glossary of terms in A Guide to the Project Management Body of Knowledge (PMBOK® Guide):

“Backlog. A listing of product requirements and deliverables to be completed, written as stories, and prioritised by the business to manage and organise the project’s work.”

4 Tips For Working With A ‘Backlog’

1. How many types of Backlog are you using? Scrum refers to the Product Backlog and Sprint Backlog, whilst Scaled Agile Framework (SAFe) references a backlog at Portfolio, Value Stream, Program and Team level. What is appropriate in your environment? Make it easy for people to understand what level of backlog you are referring to.
2. Who ‘owns’ the backlog? This relates to the first tip – depending upon the level/type of backlog, ensure the appropriate ownership. For example:In AgilePM®, the Business Visionary is accountable for the Prioritised Requirements List with the Business Analyst being responsible for eliciting and defining requirements. And yes, the backlog needs to be owned and reviewed accordingly on a regular basis.
   

   
   “The Product Owner is the sole person responsible for managing the Product Backlog” whereas “The Sprint Backlog …belongs solely to the Development Team.”
   The Scrum Guide™

3. Try User Stories. Try writing requirements in a backlog in the form of a user story:
   As a <role>, I want to <function>, so that <benefit>The idea is to focus on people and roles that interact with the product; as such, user stories should enable discussion to gain a thorough understanding of what the customer really needs. User stories should start, not end, a conversation.

4. Ensure the backlog is prioritised. A backlog that isn’t prioritised is simply a list; prioritisation is essential to the use of backlogs in agile. Prioritisation can be achieved through MoSCoW (Must have, Should have, Could have, Won’t have for now) or Ordering (1,2,3 etc.). Remember, prioritisation is not once-off; it should be continual to ensure that priorities remain true, enabling deadlines to be met, whilst maintaining the level of agreed quality.

 “In simple terms, new features for a product are held in a prioritised list called the product backlog.”

PRINCE2 Agile®, AXELOS

PMI and PMBOK are registered marks of the Project Management Institute, Inc.

PRINCE2 Agile® and MSP® are registered trade marks of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved

The Scrum Guide™ is a trade mark of Scrum.Org and ScrumInc.