Who Create Product Backlog Items or User Stories in Scrum

Who Create Product Backlog Items or User Stories in Scrum?

5-6 minutes

This question is a little more complicated than it sounds. First of all, you may say a product Backlog Item cans range from use cases, epics, User Stories, or even bugs, or timeboxed research tasks that reside on the product backlog.

In the simplest definition the Scrum Product Backlog is simply a list of all backlog items(PBIs) that needs to be done within the project. It replaces the traditional requirements specification artifacts . PBIs reflect the needs of customers or stakeholders. A common way to incorporate the end users’ needs is to write the PBI in the form of a User Story .

Who is responsible for maintaining the product backlog?

The Product Owner (PO) “owns” the product backlog on behalf of the stakeholders, and is primarily responsible for creating it . It is not necessary for a PO to create the backlog personally – he or she may instruct the development team and/or the Scrum Master to help him/her in defining the backlog items and in estimating them. The PO is held responsible for the creation and upkeep of the product backlog. Therefore, the PO also oversees the backlog refinement process.

The product backlog corresponds to your project plan, the roadmap for what the team plans to deliver. After the team define it, the team have a prioritized list of features and requirements to build. The product backlog also provides a repository of all the information the team need to track and share among themselves.

Product Backlog Items = User Stories?

As mentioned above, PBIs reflect the needs of customers or stakeholders. A common way to incorporate the end users’ needs is to write the PBI in the form of a User Story .However, PBIs cans range from use cases, epics, User Stories , or even bugs, or timeboxed research tasks that reside on the product backlog. In fact, not all items in a product backlog will be at the same level of detail at the same time as shown in the Figure below:

Detailed product backlog

PBIs that we plan to work on soon should be near the top of the backlog, small in size, and very detailed so that they can be worked on in a near-term sprint . PBIs that we won’t work on for some time should be toward the bottom of the backlog, larger in size, and less detailed. That’s OK; we don’t plan to work on those PBIs anytime soon.

As we get closer to working on a larger PBI, such as an epic, we will break that story down into a collection of smaller, sprint-ready stories. This should happen in a just-in-time fashion. If we refine too early, we might spend a good deal of time figuring out the details, only to end up never implementing the story. If we wait too long, we will impede the flow of PBIs into the sprint and slow the team down. We need to find the proper balance of just enough and just in time.