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.
Best Scrum Software Every Project Needs
A powerful scrum software that supports scrum project management. It features scrum tools like user story map, product backlog management, sprint backlog management, task management, daily scrum meeting, sprint planning tool, sprint review tool, sprint retrospective tool, burndown, impediment, stakeholder and team management.
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.
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:
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.
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.
So, to answer to question, the product owner who owns the product backlog, but it is not necessary for a product to create every backlog items. Typically the product owner might create large PBIs according to the high level requirement or user goals, the will then help the product owner to break down the large items into user stories as it move to the top of the backlog as some “sprintable” user stories. These Sprintable user stories are typically under “the Definition of Ready” for transferring to the Sprint Backlog.
| About Visual Paradigm |
 Visual Paradigm help organizations stay competitive and responsive to change faster and better in today’s fast changing environment. Our award-winning products are trusted by over 320,000 users in companies ranging from small business, consultants, to blue chip organizations, universities and government units across the globe. It enables organizations to improve business and IT agility and foster innovation through popular open standards and process frameworks.Visual Paradigm, a killer Agile feature in 2018, introduced Scrum Process Canvas for automating the way a Scrum team to create, manage and deploy software application that empowers the team to continuously improve their performance at unprecedented speed and scale.
Manage the Entire Scrum Process in One Page
|
