I know that the Sprint Backlog is a subset of the Product Backlog which contains the tasks to be completed in the current Sprint. Does this mean that the Product Backlog should be fully ready and complete at the beginning of the project? Should it be reviewed at the beginning of each Sprint?
Add a comment
|
4 Answers
There's no such thing as a "fully ready and complete" Product Backlog.
The Product Backlog is emergent and frequently changes throughout the Sprint. Your Product Owner will probably be talking to stakeholders throughout the effort, and those conversations will result in changes to the Product Backlog. The Developers, while doing work in the Sprint Backlog, may see opportunities to improve the product that can't or shouldn't be done in the Sprint, so they may add Product Backlog Items. During product backlog refinement activities, the team may be decomposing, reordering, adding, and removing Product Backlog Items from the Product Backlog. The Sprint Review is an explicit opportunity for key stakeholders and the team to come together to inspect and adapt (change) the state of the Product Backlog (including the Product Goal, the Product Backlog Items, and their ordering).
-
ok thanks for in this case what is the differences between Product backlog and the spring backlog ? Mar 26 at 10:39
-
@NETCoreSharePoint The difference is exactly what you said in the question. The Sprint Backlog consists of a Sprint Goal, the Product Backlog Items selected for development in the Sprint, and the team's plan for achieving the Sprint Goal.– Thomas Owens ♦Mar 26 at 10:41
-
so in this case where we define all the requirements for the project/product ? if both the Product backlog and sprint backlog will be scoped to the current sprint only.. based on my reading is that sprint backlog is a subset of the product backlog, and the product backlog contain a prioritized requirements for the whole product/project Mar 26 at 10:46
-
@NETCoreSharePoint The Product Backlog is indeed where you keep all of the known requirements. However, over time, you may find that some of those are not necessary. Others may emerge over time. When you use agile methods, you acknowledge the fact that you cannot know all the requirements up-front. Contrast this to plan-driven methodologies that do attempt to capture all the requirements up-front and have complex change control processes when new requirements are discovered.– Thomas Owens ♦Mar 26 at 10:49
-
yes i know ,, but at the end we will have requirements for the whole project (these requirements can change by time) and requirements or the current sprint .. so the first should go to the product backlog while the later should be inside the sprint backlog, am i correct? Mar 26 at 10:51
The product backlog is a list of all the work we expect to do on the product. Some of the items on the product backlog may be ready to be started, but other items may just be outlines, with more detail required.
The product backlog should contain at least two sprints worth of work but more typically it contains 3 months or more of work in a variety of states of readiness. The product backlog is never fully prepared. It is a live, dynamic list that will be refined by the team and by the Product Owner continuously.
In Scrum we work in sprints, which are time-boxed iterations. We could work directly from the product backlog in a sprint, but it makes more sense to use a more concrete subset of the product backlog which we call the sprint backlog. The sprint backlog is the work we anticipate completing in one sprint. It will contain work items that are fully prepared and ready to be started.
answered Mar 26 at 14:48
The Product Backlog Defines an Emergent Product Goal
Does this mean that the Product Backlog should be fully ready and complete at the beginning of the project?
No. It should have sufficient information to provide an initial Product Goal, but the cone of uncertainty is usually too large at the start of most projects to have a "fully ready and complete" set of specifications. Scrum is about just-enough and just-in-time planning, rather than big upfront specifications. The 2020 Scrum Guide describes this aspect of the Product Backlog as follows:
The Product Backlog is an emergent, ordered list of what is needed to improve the product...The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against.
Product Backlog Refinement is an Ongoing Activity
Should it [the Product Backlog] be reviewed at the beginning of each Sprint?
Yes and no. You have to review the Product Backlog during Sprint Planning to select items from the Product Backlog that form a single, cohesive Sprint Goal and can be done within a single Sprint. However, refinement of the Product Backlog is no longer a separate event within Scrum. The 2020 Scrum Guide says (emph. mine):
Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.
So while selection from the Product Backlog is a Sprint Planning activity, and some refinement for items selected for the Sprint Backlog is expected, Product Backlog Refinement is an ongoing activity. "Ongoing" is not defined for you, though; it's up to the Scrum Team as a whole to collaborate with the Product Owner to ensure that Product Backlog items that are likely to be in scope soon meet some team-defined Definition of Ready that includes (but is not limited to) an expectation of being completable within one Sprint.
The INVEST mnemonic is often a good guide for Backlog Refinement and can help form the basis for your Definition of Ready. However, the Scrum Guide largely leaves how the team does refinement and how much detail is required for a Product Backlog item to be ready up to the self-managing team.
While a Product Backlog item must meet the framework's requirement that:
Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.
it doesn't say you have to stop there, or even that such is sufficient. It simply sets a minimum baseline around which the Scrum Team can then create additional working agreements as needed. This is a core aspect of Scrum's empirical inspect-and-adapt control process, and provides the team with flexibility so long as the foundational requirements are met.
answered Mar 28 at 5:42
Does this mean that the Product Backlog should be fully ready and complete at the beginning of the project?
Not, the only thing that the PO needs to start a Product Backlog is some ideas, briefly written as a phrase or 1 or 2 lines. That's it. The better they are written, the easier will be the refinement. Later, the ideas are discussed and the whole team elaborate on them to narrow down the scope of those ideas. If the scope is too wide, the team may decompose an idea into smaller ones. This can happen several times until the team find the scope manageable. When a Product Backlog Item is considered "manageable" by the Dev Team, it's considered "Ready". Ready for what? To be pulled to a Sprint Backlog.
Should it be reviewed at the beginning of each Sprint?
The Product Backlog is always in motion. It's alive. But you are right, for developers to work on new product backlog items, these items should be refined. Scrum Guide won't tell you when and how to do it. Probably because you do it often no matter the moment. Especially at the beginning, when the lack of definition is absolute. So, each team do what best work for them.
What are the differences between the Product Backlog and the spring backlog?
Some relevant difference are
Scope: The Sprint Backlog is a subset of items extracted from the Product Backlog. These items are not selected randomly, they are selected to achieve a goal (the Sprint Goal) which is crafted and agreed upon by the team. Although, the PO will influence a lot.
Ownership: Sprint Backlog is owned by the Dev team. Only. No one else manages the Sprint Backlog. The Product Backlog is managed by the PO and Devs, but PO remains accountable all the time. The PO has the last say about the Product Backlog and the order of the items.
Lifespan: While the Product (or Service) exists, the Product Backlog exists. Even if it's empty. The Sprint Backlog lifespan is equal to the Sprint length (days, weeks, 1 month at most)
Goals: Both Backlogs have (as described by the Scrum Guide) a goal. These goals are a sort of "commitment". Product Backlog has the Product Goal and Sprint Backlog has the Sprint Goal. The Product Goal is a long term commitment. The Sprint Goal is a desired outcome for the next X days. A short-term commitment. Think of Sprint Goals as a sequence of milestones toward the Product Goal.
