Demystifying Product Backlog Canvas

Understand the elements that make up Product Backlog Item(s)

Estimated Read time for this article: 7–9 minutes

Targeted Audience: Beginner or Intermediate Business Analyst / Product owner / Any Delivery team member

Suggested Prerequisites: Agile / Scrum

Upon Completion you will:

  • Know what kinds of items can be found in a Backlog
  • Know at least one format to write each type of item

— — — — — — — — — — — — — — — — — — — — — — — — — —

We all recognize that change is a constant in the business world, and the changes in business, market conditions, or technology may enforce realignment of product roadmap and in turn your software product backlog. Thus, it’s important to understand that the Product backlog is never static and complete. The items underneath will also be different depending on scope /situation or the phase.

For most of the people working in Agile development methodology, the term “Product backlog” has become an apparent synonym of Master story list containing a collection of functional stories lined up to incrementally deliver value, which is not always true as a backlog can house multiple type of items underneath and still can deliver value. So, Just considering it as an encapsulation or a shell containing functional stories can become counterproductive.

Because of the same reason, it is quite possible that you have seen user stories with Narration that state something like

“As a product owner I want to move code from service fabric to domain service so that I can reduce the infra cost”. Or narration which starts with “As a system / developer / Quality Analyst”.

This happens when the team or the BA forces a Non user story type of work into a functional format, which is like trying to adjust a square peg in a round hole.

Simply put, Product backlog containing such items can become unmanageable and not easy to prioritize. Thus lets understand with some examples of items a PBI can hold depending on the phase or type of the project and how we can write them up without the core objective.

P.S: In this article, I’m not going to pronounce which type of PBI or the format is best as each one has its own advantages and disadvantages depending on the situation. So pick the ones which fit into your case and help you in managing the requirement easily and clearly.

Product backlog & Its Taxonomy:

Below is a usual product backlog items that are found in a fresh engagement, lets digest the infographic and bullets below to read my thoughts on the same:

Product Backlog Item Types — PBI(s) types

1# Functional Requirements: These are simply an articulation of requirement in an artifact which keeps product need or want from an end-user’s point of view. This can further be divided into a hierarchy established by key stakeholders to define and divide the immensely complex large quantum of system functionality into manageable / trackable pieces.

One can use popular scrum defaults like Epics to describe a huge chunk of system functionality, which can be divided further into features describing work that need to be completed, which are in turn splitted into user stories or use cases.

Examples of narration in such stories:

Title:”Add ability to sort the search results

Narration: “As an Authorized logged in user, I want to Sort the search results So that I can get to the relevant information quickly” Or

Title: ”Allow jpeg file format files to be used

Narration: “As a logged in user I want to able to upload JPEG format profile picture so that I have more flexibility and use pictures apart from PNG”

The other challenges while taking a stab at feature for user story slicing is around involving the technical work to develop that capability, which generally are the first building blocks you put together before you begin a functional piece, in this case always try to minimize the functional part deliverable and increase the tech quotient in the very first story. Like in the first user story, you can create a page with certain functionality which receives a mock response from a fully setup API and in the next one you add more UI fields on the page with a full blown API response. So, by doing this you remove a need for a separate technical story and incrementally delivered value.

2# Non Functional Requirement: If building a large Platform or complex product you might want to define items which tells how a system is supposed to be, it can again have hierarchy like Functional requirements but it is different conceptually, thus it helps if we create a separate backlog item type for NFR or even if we decide to use the same then we shouldn’t force the User Story Format all over the place, meaning don’t paint everything with same brush.

Below are some Narration examples with type:

Performance: “As a logged in user I want my page to be loaded in one second so that I can interact with the application quickly”. Notice, the same format as Functional can work here.

Security: “As a hangout user making a video call I want my data to be encrypted over video communication so that only authenticated people can access my data” Notice, the same format as Functional can work here, but might not work for below example:

“As a tester I want to run wireshark on DEV environment so that I can run security assessment tests and compile a vulnerability report”

While this story put together the functionality required but I think it is overkill and can be rephrased unpretentiously by writing:

“Need to set up a wireshark security tool on the DEV environment for running scripts to catch up and fix the vulnerability early in the development phase”.

The important point is that if you are too determined to format a technical requirement into ‘As a, I want to, So that’ then you might lose the essence of it, so simply write it the best way you can articulate in plain english and move on.

3# Spikes: SMART(Specific, Measurable, Achievable, Relevant, and Time-boxed) experiment that allows developers to explore something unknown in a user story / epic or the requirement in order to reduce the risk or uncertainty on it. Sometimes, it is just exploration / documentation and in some cases, it’s also about doing technical analysis to finalize the approach by doing proof of concept. While writing up this one should understand that it is something which can’t be related directly to a user value so formatting it would not give any benefits.

[SPIKE] How do we integrate with Paytm, a 3rd party mobile wallet service?

Notes: This is a spike to assess the many available approaches and its effort for integrating with Paytm, a 3rd party Mobile wallet service.

Outcome: this spike is complete when we can document the finalized approach and properly estimate the card “Pay for items using Paytm”.

4# Foundational Stories: When it is a new project / new team, and I don’t yet have development / automation environments setup or I have ideas on architectural approaches, but team isn’t familiar with all of the tooling or frameworks, then I generally write foundational stories to do Initial setup to enable successful project delivery and start sprint Zero!

Example of Foundational Stories:

“Set up continuous integration server and initial test automation to deploy to Master” Or

“Set up a team secrets management system i.e. vault to keep encryption keys, API keys, database passwords, SSL certificates, etc.”

Evolving Product backlog Item types during a project lifecycle:

Whilst the new engagement has less variant of backlog item types as no legacy things exist, hence, there is possibility of additional types of backlog items in an ongoing engagement after initial few sprints which might vary depending on the needs and preferences of team members, below content and following section of article explain them as well as tell us one of many ways to articulate them.

Additional Product Backlog Item Types

5# Bugs (Defects):

The unexpected behavior anywhere in the application is captured as bugs, its definition might sometimes vary as in some engagement Bugs are found post production and defects are found during development but there is no set in stone kinda rule here and these terms can be interchangeably used but important part is that there are high chances of Bugs / defect featuring in the product backlog item of an existing engagement or an legacy application. Again, the write up / format and the content is different from the other types which makes it a manageable entity and easily identifiable.

6# Improvement: Not all might have seen this type yet, but it’s also a good one when building an overwhelmingly complex software application as there are high chances of feedback which are enhancement that are popping up after the client sees the working demo, it gives you a clear demarcation of original scope vs additional scope and also helps you keep those satisfiers out of your MVP until criss crossing your critical path.

Example of Improvement / Enhancement

Title: “Enrich the search page with Additional budget filter”

Narration: “As an user I want to apply a budget filter on search result so that I only get hotels within my budget”

7# Technical Debt: When a conscious decision has been made to take a shortcut in order to get a task completed quicker by delivery teams to prioritize speed and expedited delivery over investing in perfect code. The analogy is to financial debt: You don’t have to pay down the principal now, but the longer you don’t, the more interest you accrue. So like in business, it is good to take on debt to grow faster but it’s not advisable to delay the payment or not repay as Cost of change of doing them a little later can harm more than doing good. So it’s always best to make appropriate timely repayment by prioritizing technical debt in sprints to prevent Technical Bankruptcy!

Due to these factors of hidden customer centric value, it is advisable to track Technical Debt as a separate backlog item and document properly to define its objective and the value is reflected. So that business stakeholders can agree for prioritization.

Examples of Tech Debt:

[Tech Debt Item]: Common Repo Management and movement of components

Rationale:

  • Need a better method to store and reference common UI components from a centralized place.
  • This will clean the code and there will be consistency across applications in behavior.

Tech Improvisation: It will increase the velocity of the delivery team when working on future feature development as once the components commonly used in UI are moved to a common place it will be just a case of referencing / overriding on the feature itself.

8# Change Request: Similar to Improvement as there is some request from client to alter / add or update in how system is getting build today with the MVP scope in hand but slightly different the way it is dealt with as client in this case might be pursuing delivery team to bake in the change scope request into the MVP scope itself, so it’s imperative to keep it as a separate product backlog item and track it separately to gauge and communicate efforts needed or to even have a meaningful discussion around scope creep.

It can be written similarly the way functional stories or Improvements are articulated / Formatted.

Anatomy of Evolving Product backlog

As I explained in the above section, product backlog and its taxonomy changes depending on the phase of product development, thus it’s imperative to understand that initially the PBI will only have capability or initiatives needed in the product to fulfil the user needs in a less granular way. Which after doing prioritization and release planning shapes differently with additional backlog element type, and further it adds more elements after playing a few sprints. Below diagram depicts the same in a pictorial way:

Evolving Product Backlog
Evolving Product Backlog
Evolving Product Backlog

Selecting & defining product backlog Item depending on need is the key:

Selecting backlog Item:

While working on creating or refactoring product backlog items, remember to select the appropriate one from the ”8 backlog item type” explained here or pick the custom defined one in your project but remember the intent of each type must be unique and if the delivery team feels an ambiguity between them or something is missing, then merge a few or create more. But the penultimate thing is to make sure you make a clear and shared understanding of each backlog item type and select them well!

Writing backlog Item:

For the content in each type, I have mentioned a few examples for each type as guiding lights but the takeaway is not to over engineer anything by putting a fixed format for title / narration of each type, and it is advisable to keep them the way the team prefers and understands. Plus nothing is set in stone and you can create your own path. My past experience has shown that the impulsive use of the term “Master story list” and the “user story” has led to confusion and dissatisfaction in the requirement management space and has often generated an ill-defined or ill-prioritized list of requirements.

Making clear distinctions of work types helps to ensure they are oiled well as their needs and made ready according to the definition of done. Understanding what information a backlog item must contain and what checkpoints it must cross before it is included in a sprint backlog.

I hope you have found this article informative and engaging. Any constructive feedback is appreciated so please do post a comment!

Business Analyst

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store