Recently a business analyst, who was studying for their ECBA exam, asked me what the difference was between a Requirements Repository and a Requirements Backlog? I though it a good idea to share my thoughts, so in this post we will discuss the differences between a backlog and repository and provide some tips on both. But before we dive into the explanation, let's understand where the words originated from and how it relates to our current understanding of projects.
Let's start with what BABOK® says: "A backlog occurs when the volume of work items to be completed exceeds the capacity to complete them." While a repository is “a real or virtual facility where all information on a specific topic is stored and is available for retrieval.”
Backlog: a large log placed at the back of a fire
The evolution of a backlog
Backlog (also back-log), was first recorded in the 1680s, as a "large log placed at the back of a fire" to keep the blaze going and concentrate the heat. By 1883 this word and meaning changed to a figurative sense, meaning “something stored up for later use”.
Nowadays we understand a backlog in terms of an agile approach to the way in which we work. In scrum, the agile product backlog is a list of all the features that need to be in the product, with short descriptions of each. When using scrum or another agile development methods, it is not necessary to spend a long time at the beginning of a project writing down all of the requirements. This is how traditional project management methods like the waterfall model usually work. Instead, a scrum team and its product owner will typically start by writing down every relevant feature they can think of for the project's agile backlog. The initial agile product backlog is almost always more than enough for a first sprint. The scrum product backlog is then allowed to grow and change as more is learned about the product and its users during the project's life cycle.
Building the Backlog
It's important to remember the Pareto rule when you're developing your product backlog because most of your users will get 80 percent of the value of your product from 20 percent of those features
In this video by Devin Deen, he discusses how to build the product backlog. He explains that when you start gathering requirements, it's important to group items in terms of ...
- how much it's going to cost to deliver that item,
- relative to one another is it expensive or less expensive,
- is it a big item to deliver or a smaller item to deliver and then of course,
- the perceived value that you think your customers will get out of that particular requirement or feature these are the items that you want to focus on delivering,
He goes on to add that: "It's important to remember the Pareto rule when you're developing your product backlog because most of your users will get 80 percent of the value of your product from 20 percent of those features, which is why a prioritised list of requirements or user stories is really important when you're forming that product backlog."
What is a requirements repository?
Repository in classical Latin refers to "a stand on which food is placed," and by 1640s is the word was used more in the figurative sense, as a “store”.
According to BABOK® 3.4, business analysis is all of the information that business analysts gather, create, compile, and share as part of their work. Models, scope statements, stakeholder concerns, elicitation results, requirements, designs, and solution options are just a few examples. This includes requirements and designs, such as user stories, formal requirement documents, and prototypes that work.
One of the tasks we need to do is figuring out how information should be organised,
- how much detail should be recorded,
- if there are any connections between pieces of information,
- how information can be used across multiple projects and across the enterprise,
- how information should be accessed and stored, and what information needs to be kept.
Information management helps make sure that information about business analysis is organised in a way that is functional and useful, is easy for the right people to find, and is kept for the right amount of time. There are many ways to store information and decisions about where to store information depends on multiple factors, like"
- who needs to access it,
- how often, and
- what conditions must be met.
"Requirements Tools Don’t Do Analysis — a Business Analyst Does" Yulia Kosarenko
Storage and access decisions are also affected by organisational standards and the tools that are available. Tools can affect how business analysis techniques are chosen, what notations are used, and how information is put together. It's possible that the repository will need to store more than just requirements and designs. Just like storing of food so that we can eat it later, so too we sometimes store requirements for reuse. Having a great repository that is well catalogued, categorised and managed is a real asset to our change projects.
Business analysts should still analyse, even if there is a repository!
You may be thinking... “All of our requirements are now tracked in this tool”. “You don’t need to create documents anymore”. “Just make sure you populate all the required fields”. “We now have full traceability”. “Your job is to ensure the integrity of our requirements repository”. BUT If only everything was that simple... Yulia Kosarenko
Repositories could be the answer to the problem of gathering requirements. Why? No more interviews, writing, taking notes, or filling out business requirement document templates. Just put the requirement into the tool and follow the formatting instructions, and the code will write itself.
As Julia expresses in her blog post ...If only everything was that simple. In real life, tools often have to meet high standards. Just like a large warehouse, we have to manage it for it to actually work. Depending on how they are set up and managed, and the level of governance and oversight, there will be attributes to fill in, traceability to add, names to add, versions to assign, multiple dates to keep track of, and approvals to get in a certain hierarchical order.
In this video, Yulia says:"The key message for you is this: you are not a scribe, you are an analyst. Research, investigate and analyze. Analysis first, then synthesis."
What wonderful advise - Thank you Julia!
Summary
In this post we discussed the differences between a backlog and repository and what it means for business analysts. Here are some take home lessons
- When using scrum or another agile development methods, it is not necessary to spend a long time at the beginning of a project writing down all of the requirements. A scrum team and its product owner will typically start by writing down every relevant feature they can think of for the project's agile backlog.
- A repository is all of the information that business analysts gather, create, compile, and share as part of their work. This includes requirements and several other artefacts.
It all comes down to information management, for both a repository and a backlog to help business analysts organise, analyse, and synthesise information in a way that is functional and useful, easy for the right people to find, and kept for the appropriate amount of time.
Happy learning
Post a Comment