Product Backlog Items

Overview: –

By now we’ve learnt that products serve as a medium to solve a problem or improve, enhance or optimize an age old routine task. Every product germs out of a great idea, an initiative or an identified problem that needs to be solved desperately. But in order to bring this product to life from a power point presentation or an exhaustive document or a speech on building castles in the cloud, it needs to a structure in place, a one that is easily understood and that can be executed in a disciplined and timely manner. Traditionally, lets say from the times of Industrial Revolution, humans worked and have continued to work on “Projects”. A Project Manager builds a structure of activities that need to be performed in order to complete the project, called the “Work Breakdown Structure” which would be derived from a “Project Plan”. The structure consists of smallest unit of work or work activity, called the “Work Breakdown Element”.

But wait a minute, we’re not here to learn Project Management. So, in this chapter, we will discuss, learn and unlearn how a product’s vision & goal are brought to life by building a structure and granular list of work items to build the product. The Product Backlog Items.

Let’s Address the Process Dilemma First: –

In most organizations, matured and big, generally the process goes as, a PM discovers the product, presents the product idea, drafts a Product Requirement Document while simultaneously working alongside org leader and clients to planning the release, comes back to PRD while now creating a structure called “Product Backlog” with Product Backlog Items, adds in the PRD, presents the PRD and development begins. Exhaustive. So, to make things easier to start with without convoluting the learning with rules of process for now, we will learn what Product Backlog and Product Backlog Items are while also drafting a development ready Product Requirement Document in the process.

Let’s start.

Context: –

Every concept we’ll learn today will be directly linked to the product we’re building, The IRONMAN. So if you’ve come here new, spare a few minutes to understand what we’ll be building in the due course of time.

Additionally, we will be using JIRA as the product management tool to articulate requirements and build the product backlog. DO NOT get intimidated by it if you’ve never heard or worked on it. It’s just a tool.

Product Backlog: –

An emergent, ever increasing ordered list of items (work or activities) aimed to build and improve the product is called a product backlog. It is a single source of truth for work to be undertaken by a team, in agile, a scrum team. In conventional agile product management, a product backlog consists of following components: –

1. Epics
2. User Stories
3. Bugs

Since we’re learning as we build ironman, we will cover Bugs in the chapters later in the course.

Following image will show you how a product backlog looks like on JIRA. It is the one using which we’ll be building our product.

You can see Epics organized at the left while the line items being the user stories. Let’s learn both

Epic: –

Epics are product backlog items used for organizing work items, user stories in order to achieve an overall business need or outcome. In some practices, epics are commonly referred as features that consist a breakdown of what needs to go in to build it.

Let’s take an example from our product backlog. Selecting, “Customer- Login/Signup” Epic, we see a list of user stories created under it in order to build a functionality and workflow to allow customers of Ironman to register and login.

User Story: –

A user story is the smallest component in terms of hierarchy in a product backlog that articulates a set of requirements written with the view of a user, an actual user who’d be performing or using the feature on the product. User stories are designed and written keeping the classic 3C framework in mind. They being: –

1. Card – It should be small enough to be written to fit on card.
2. Conversation – The details of the story should initiate conversation within the team to understand and know details about it.
3. Confirmation – A way to define what has been discussed is the confirmed set of details to build it

Structure of a User Story:

Description: –

A widely used format in writing description of a user story goes as :-

As a <persona>, I should be able to <action>, so that I can <intent & benefit>

Here, the persona being the user, it’s type & kind with respect to it’s association with the product being built

Action is what the user would perform on and using the product in order to achieve the “Intent & Benefit” from the product

Business Flow: –

A path the user will need to follow in order to achieve the desired benefit from the product

Acceptance Criteria: –

The most important section of user story is its acceptance criteria. It encapsulates the concept of definition of done by suggesting what is expected by the user story to do in order to be termed complete and be shipped as an increment on the product. Hence the narrative while writing the acceptance criteria should be such that this is what the system does. The acceptance criteria serves the engineers and testers to build the product by serving as it’s primary source of truth for business value to be delivered by the story. Testers derive their test cases through the details mentioned in the acceptance criteria.

Here’s an example of a user story that will be used while building our application.

Takeaways: –

What we’ve learnt today is a portion of product backlog. What goes in it , what it’s made up of. I know, experienced PMs may say I haven’t explained Definition of Done, I haven’t explained Sprint Backlog etc etc. I know. But these are things which I’ll be covering in depth when we learn Product Backlog Management and Backlog Grooming.