When to consider multiple PBIs when determining the HOW?

Question

Consider that we have 10 Product Backlog Items (PBIs) that have been estimated and, if all goes well, will make it into our next sprint, after Sprint Planning. At what point would it be appropriate to have the team think about ALL 10 PBIs as sort of a way to understand the end goal of this 10 PBI effort (assuming all PBIs are associated with a common theme/epic)? While it's understood that each PBI will deliver value on it's own, it's often helpful for the team to know what is next since it can help inform technical decisions.

Meetings that I've considered for this work:

Grooming - Doesn't seem like the right time because this would be too much about the "HOW" when we should be discussing the "WHAT" Planning - Too late since the PBIs have already been defined. I always assumed that, by this time, everyone would be ready to sign up and task out the PBIs.

When is the right time to do this? Or is this a PBI quality issue?

Would this be in the tasking phase of Sprint Planning? I would think that is too late in the process, since it's possible that information gathered during this effort would help restructure PBIs.

Answer 1

The right time (or process) for it is Backlog Grooming. Its goal is to get PBI to "Ready" state. And it is not a standalone meeting, as in Scrum Guide (http://www.scrumguides.org/scrum-guide.html#artifacts-productbacklog) you can see that

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog.

It is also clearly described in Jeff Sutherland's video https://www.youtube.com/watch?v=XkhJDbaW0j0 :

Ready-ready [...] is not just a good list. It has certain characteristics.

The first characteristic that's really important is that it needs to be immediately actionable by the team. They need to know what to do and they need to be able to do something now.

If you didn't do any investigation and have no idea on how you will do it, you'll have a problem.

The second thing is that the product backlog in Scrum [...] is designed to be a negotiation [...] needs to be something that's talked through between PO and the team, before Sprint Planning.

You are right about planning being too late for this.

The next thing [...] is to be estimable. The team needs to be able to estimate it clearly and size it properly.

Unless you do technical investigation, in most cases, you won't be able to do a clear estimation. A guidance form senior technical people is invaluable in such situation.

To sum up, you need to do proper investigation as a part of backlog grooming to remove uncertainty and get your PBI to "Ready" state.

Answer 2

When to think about a block of stories together

@Alex Leonov gave a good answer covering the basics of getting stories "Ready". However, I have a different take in response to your specific question:

At what point would it be appropriate to have the team think about ALL 10 PBIs as sort of a way to understand the end goal of this 10 PBI effort (assuming all PBIs are associated with a common theme/epic)?

At the time of Sprint Planning and during the Sprint, if they have been scheduled into that Sprint. From the Scrum Guide:

"The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal."

If, as you say, "information gathered during this effort would help restructure PBIs", go ahead and restructure them during the Sprint.

Prior to the Sprint Planning these PBIs are just stand alone stories. If you do any work assuming that these 10 PBIs will stick together, that will be wasted effort. The Product Owner is free to move some up, others down and remove some altogether. Also, from the Scrum Guide:

"The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering."

Answer 3

We faced similar concern with the team and ended up having two Backlog grooming sessions during the 2 weeks Sprint. Our Schedule was the following:

• Thursday. Sprint start. Planning day.
• The team starts a Sprint and does not care about next one for couple of days.
• Monday. Standup meeting. Backlog grooming (45 min) - focus on WHAT.
• The team got a week to discuss/research/thnk over the next Sprint candidate PBIs.
• Monday. Standup meeting. Backlog grooming (45 min) - focus on HOW.
• Finalizing current Sprint with 90% understanging of what the next Sprint is about.
• Wednesday. Sprint demo. Sprint end.

That worked fairly well.

Answer 4

Themes and Epics Aren't Sprint Goals

At what point would it be appropriate to have the team think about ALL 10 PBIs as sort of a way to understand the end goal of this 10 PBI effort[?]

Never. You are misunderstanding the relationship between the Sprint Goal and the Product Backlog.

Part of Sprint Planning is the definition of an over-arching Sprint Goal. In general, all stories selected for the current Sprint should build towards that unifying goal. In this way, a Sprint can succeed even if 100% of selected stories aren't done so long as the defined Sprint Goal is met, or stories can be trimmed from the current Sprint so long as the agreed-upon Sprint Goal is not jeopardized. This is part of what makes Scrum such a flexible and powerful framework.

In addition, the Product Backlog is a series of items that have been assigned an ordinal value by the Product Owner and a relative level of effort (e.g. story points) by the Development Team. The Development Team pops items off the top of the Product Backlog one at a time, provided that there is sufficient capacity within the Sprint to complete that story within the iteration. The team never accepts stories into the Sprint simply because they are related to other stories; all such decisions must be based on:

1. The ordinal value of the stories, which can be changed on the fly by the Product Owner during Sprint Planning as part of negotiation of scope. Stories must always be popped off the top of the stack in sequence, but the Product Owner can cooperate with the Development Team to change that sequence during Sprint Planning to facilitate the composition of a sensible Sprint Backlog.
2. The Development Team's expected capacity for the Sprint. This is most often the team's velocity range, adjusted by current fudge factors that account for vacations, sick time, trade shows, or other factors that may impact team capacity during the current Sprint.

The Scrum Team must work, each and every Sprint, towards a unified Sprint Goal. At no point does the team ever consider stories on the Product Backlog this way. However, during Sprint Planning the Development Team must always keep the Sprint Goal in mind while planning and organizing the Sprint Backlog, and the Development Team should consider all of the accepted Sprint Backlog items together when planning the current Sprint.