The Product Backlog in Agile


By now most you may have heard the term “Product Backlog” in Agile terminology. You can consider this term to be referring to our erstwhile vocabulary of requirements documents with a slight twist.

Requirements Management

The point about managing requirements in Agile is that you can use any tool available to manage what is needed to build the product. It could be a wiki, it could be jIRA, it could be Rally or even an excel sheet. The means to detail requirements do not matter. What matters is how the requirements are listed, when they are ready for design and execution, when and where they are discussed with teams and how they are made more and more clearer as time progresses. We need to maintain this essence while handling the requirements.

So coming back to product backlog – think of it as a list of requirements to build a product with two important considerations: the priority to develop a listed item, and the clarity available to implement a listed item. Priority obviously means what is more important to do (even in normal life). Clarity available means what is actually Ready.



When we use the word Priority the first thing which comes to the mind is who defines this order. Is it the product owner, is it the product manager, is it the marketing guys, is it the senior management or is it the scrum team – who exactly? The answer lies somewhere in between really. The initial list is prepared after the product owner analyses the market needs but somewhere along the process lots of inputs add on to altering this list albeit in a subtle way. Firstly anyone can refine what is written on the product backlog in consultation with the product owner. Senior management can provide their inputs based on the general direction the company is taking to ensure these generic needs are also factored to build the right product that the company can sell for sometime. Not all requirements would benefit one single customer but seen as a whole many parts of the product may satisfy different customers for what they need.

Most times to achieve a certain set of market requirements the engineering team needs to build a robust base on which these requirements can be built. These are system level foundations or engineering enablers which the team has to put in place to keep the product extensible, componentized, and scalable over a period of time without investment of huge amount of effort. Customer A might need feature 1, 2, and 3 – B might need 3 & 4 but in order to offer all these features the base needs to incorporate subcomponents i, ii & iii – which is what the engineering team will come up with as input. It could be putting common elements into a library, or building frequently used functionality as APIs or deeper system level stuff that defines the architecture which the product will tend to use during its regular functioning.

These discussions yield a more detailed set of backlog entries which are groomed to add the necessary amount of additional stuff to make the requirements more complete. This also helps while committing a holistic solution to a customer and to better explain in depth certain aspects if customers ask for details.

So what then is Priority based on? – It is really a combination of a few things in reality. Some of the considerations include

  1. How badly does a customer need a feature?
  2. What are the set of things if done forms an MVP – minimum viable product?
  3. Are there items in the list which also cater to management direction indirectly or directly benefitting the customer?
  4. Are the items on the list ordered in such a way the customer benefits by being first to the market with the feature giving him a competitive advantage?
  5. Are the list of requirements clear enough that they can be implemented in as early as the upcoming sprint?


Most times teams expect the requirements to be so detailed that the only thing they then need to do is simply implement them. But there is a small problem with this way of working – it misses out on an essential activity in the agile way of working – conversation and collaboration. If the requirements are so clear to the level of code it is called design. We use the oft known aspect of requirements to avoid this situation – the requirement must only state what is needed. Any questions on how it is to be achieved is best avoided at the time of detailing the requirement. So does this mean discussion on design aspects are not to be done during grooming? No, not exactly. It is always useful to capture notes as much as possible when there is clarity. The only point here is sometimes there are hundreds of small requirements that need attention and if we start dwelling into the design at each and every point, the whole process will become cumbersome, waste valuable time of the team who are already implementing something else and generate a lot of info that may not be really needed at definition stage.

A requirement must be defined to be able to bring people to the point of asking questions. For example consider a common example of a login screen in the context of year 2018. The requirement for example is stated as “Users shall be able to login to the application”

Definition of Ready

Fantastic. But its not clear enough. It is not ambiguous, but not really fully outlined either. For example think of the questions you may normally have if you read the above need. I can list a few on top of the head below:

  • Should the URL for login be a secure website (https://)?
  • Would the login be based on username and password?
  • Would there be a captcha that the user has to enter to login?
  • Would the login support OpenIDs such as Google?
  • Does it entail an additional step of a Google Authenticator code?
  • Does it have SMS based 2 factor authentication check?
  • Should the login mechanism be different for devices running different operating systems (apple, android?)
  • Is there a need for forgot password and forgot ID options?
  • Where must the flow land after successful login?
  • How many attempts must the user be provided after which the login will be restricted for sometime? Is there a need for such a restriction at all?
  • Should the captcha be text based or puzzle based (mouse) ?

If by myself I can come up with such questions in less than two minutes, think of what will happen if there is a discussion amongst the team reviewing this requirement. Does this mean all these questions will become additional requirements? Maybe some will, but not all would. There are few ways to handle these questions. Some maybe entirely new requirements, some would be added to existing requirement as part of the requirements, some would be part of the acceptance criteria to validate that the requirement was completely met in design and code, and some of them may be excluded as well.

In order to make the requirements Ready it is important that the discussions are conducted with different groups during the iteration. A requirement that is not ready cannot be implemented by the team. What this essentially means is simple: Any requirement where the team has not had a chance to ask questions and clarify their doubts is not considered ready. Again a very important thing to remember here is that the people raising questions on the requirement/s SHOULD NOT tend towards the how the requirement must be implemented part. That is design. They should just focus on the WHAT is supposed to be implemented part.

Conclusion – the importance of conversation and collaboration

I cannot stress this part enough. Most of us, however experienced we are tend to move the discussion from the what part to the how part. One has to constantly remind ourselves to refrain drifting to the how part unknowingly. It is not unreasonable to even question once in a while whether we are discussing the design or just the requirement. So once the requirement queries have been addressed it is considered Ready as long as there are no more open questions from anyone on WHAT is needed. Sure they maybe still some questions lingering to be answered but that may not really help clarifying the requirement further and may go into some fringe discussions beyond what the requirement intended to address.

To conclude some general points about the Product Backlog

If the product backlog is divided into two parts the top and bottom,

The Top

  • has requirements that are needed by market and customers as soon as can be delivered
  • has items that teams have discussed a lot upon and are ready with a decent amount of clarity
  • product owner has broken down some monolithic requirements to a level where it is split into many smaller parts which are achievable by teams in every iteration
  • is fine grained to the level the teams can continue discussing design details to further make the requirement ready for implementation at the nearest possible opportunity

The Bottom

  • has items that has less clarity at the moment
  • has items that are needed by customers but not right away and can wait
  • has items that are not yet discussed with teams even though customer may need it shortly hereafter
  • has items that are at a higher level and not yet fully addressed with respect to acceptance criteria to make it clear to the teams implementing them
  • has not yet got a chance to be groomed even at leadership level
  • has items that the market may not need right away or there is no visibility of when and whether the product intends to keep those features
  • has items that have too many dependencies which need to be discussed and addressed


These parts of the backlog are called fine-grained & coarse-grained respectively.

We will discuss more on Grooming, acceptance criteria and few other topics in the next few posts.


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s