PBI to Sprint Backlog Item

No.
Absolutely, the Item will not be "Done" in the end of the sprint.

A big story, epic, must be decomposed to small story.

No. Use the INVEST model to break down stories to a more granular level. PBIs should be of small enough size such that they can be Done according to the DoD within the sprint timebox.

For most teams PBIs fall in the range of 1-8 in size which tend to be more refined. Stories bigger than that tend to carry a higher level of ambiguity, complexity and risk and more likely that they won’t be Done within the sprint timebox.

Collectively all user stories should sum up to match the team velocity and the relevant team capacity – this will be the sprint goal. I also recommend adding a stretch goal as a challenge for the team if the team has the capacity.

Jitesh

> Can a single Product Backlog item when converted to sprint
> backlog items span over multiple sprints ? In other words, can
> a single pbi be done in multiple sprints

A team should plan to complete each selected item, in full, to the standard of the Definition of Done.

If by the end of the Sprint any item remains undone, the outstanding work should be re-estimated and made visible on the Product Backlog. It can then be prioritized, refined, and planned into a future Sprint for completion. Note that incomplete items do not automatically roll over into the next...this is a planning decision.

> I also recommend adding a stretch goal as a challenge for the team
> if the team has the capacity.

I don't generally approve of stretch goals. They can imply that if they are not achieved, then the team has not bothered to stretch itself. Nor are they a timely way to make use of capacity, should any become available.

It's best for a team just to make the most realistic forecast it can, and to reflect that in the Sprint Goal and the Sprint Backlog. If any free capacity becomes available once the Goal has been met, then the team can decide what to do at that point, using the most current information. They may decide the best thing to do is to plan new work into the current Sprint, or they may decide it is wiser to do something else entirely.

I agree with Ian.

Team members must work at a sustainable oace.

My experiences, within a given sprint, eventhough there seemed be any free capacity becomes available, we would see intensity increase a little bit near the end of the sprint.

It's best to for the team to make decision by themself.

Thanks for your insight Ian, I understand your point of view, and generally this approach works well with many teams until they reach a plateau and need a little nudge.

> They can imply that if they are not achieved, then the team has not bothered to stretch itself.

Teams should be stretching themselves and this is a way to highlight just that - why hide it? Some teams I have worked with became comfortable and laid back at ~52 points per sprint. I used stretch goals to instill a different mentality in the team - the stretch goal is visible on the board below the sprint backlog in a different section and used it to drive additional continuous improvement tasks during retrospectives to streamline processes, working agreements and techniques even further - "How could we have reached the stretch Goal?" - this began to drive a different way of thinking.

I certainly have that mentality - "how could I have done more and better? How can I improve?" - certain teams need that slight nudge to get them going again.

Jitesh

Hi Ching-Pei

> intensity increase a little bit near the end of the sprint

This is undesirable team behavior and should be tackled as much as possible during a retro with supporting metrics.

> It's best to for the team to make decision by themself

The team decides if it has capacity to pick up the stretch goal, absolutely.

Jitesh

> Teams should be stretching themselves and this is a way to highlight just that - why hide it?

There's no such thing as a stretch goal in Scrum, and no expectation that teams should stretch themselves at all. The expectation is that teams should be able to forecast the best possible increment of value that is fit for purpose, and then that they deliver that increment. There's also an expectation that they should be able to replan in a timely manner should capacity be available once the agreed Sprint Goal is met, and then inspect and adapt their method of forecast accordingly.

Trying to identify in advance how unplanned work should be progressed is neither timely, nor is it a good means of providing an optimal forecast.

I agree Ian there is no such thing as a stretch goal in SCRUM however it doesn’t stipulate that teams can't have one either.

SCRUM is a framework within which teams can employ various processes and techniques to maximise value. This is true as long these processes and techniques don’t drive certain dysfunctions - this goes for all processes and techniques developed within SCRUM.

Enforcing or predicting how certain techniques, processes or methods are going to work/should work within SCRUM holds teams back from experimenting which is a dysfunction in itself.

There is no right or wrong answer, the SCRUM framework enables teams to experiment with whatever process or technique they wish to inspect and adapt within it, and this includes any estimation and forecasting methods.

> This is true as long these processes and
> techniques don’t drive certain dysfunctions

That's just the point...stretch goals are likely to drive certain dysfunctions. These include anticipating what unplanned work a team will do if future capacity is available. That encourages waste, because it isn't a timely decision. Also, it shifts the team's focus away from the Sprint Goal and from giving the best possible forecast for that work alone.

I therefore don't generally recommend their inclusion, as the integrity of a Scrum implementation can too easily become compromised.