5-6 minutes<\/p>\n
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.<\/p>\n
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\u2019 needs is to write the PBI in the form of a User Story .<\/p>\n
The Product Owner (PO) \u201cowns\u201d 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 \u2013 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.<\/p>\n
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.<\/p>\n
As mentioned above, PBIs reflect the needs of customers or stakeholders. A common way to incorporate the end users\u2019 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:<\/p>\n
Detailed product backlog<\/p>\n
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\u2019t work on for some time should be toward the bottom of the backlog, larger in size, and less detailed. That\u2019s OK; we don\u2019t plan to work on those PBIs anytime soon.<\/p>\n
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.<\/p>\n","protected":false},"excerpt":{"rendered":"