User Story too large to do by end of Sprint

A few questions for the team before pulling in a new PBI:

• Has the Sprint Goal been met?
• Did we create at least one valuable, useful product Increment this Sprint?
• Did we complete all action items from the past Sprint Retrospective that we said we would finish this Sprint?
• Would pulling in this new PBI jeopardize our Sprint Goal or Done Increment?
• Do we have any lingering technical debt that should be cleaned up?
• Does the team need any additional cross-training to help them be more cross-functional?

Thanks Chris - the work they request to be pulled in is part of the Sprint goal. So they got through their PBI's but now there is some space, they want to pull in the next backlog item but its far too large to fit in with the remaining days. 

Some other good suggestions there. 

John - I'm confused. If the new PBI they want to pull in is required so the Developer's can meet the Sprint Goal, the next step is for them to negotiate the scope with the Product Owner so that the PBI can be finished by the end of the current Sprint.

If the Sprint Goal is intended to span more than one Sprint, perhaps the Sprint Goal is too vague and that should be discussed in the Sprint Retrospective.

All the best,

Chris

the work they request to be pulled in is part of the Sprint goal. So they got through their PBI's but now there is some space

What commitments have they made, and have they met them at this point? Perhaps this matter is not as transparent to the team or to others as it ought to be.

I'm confused by this situation.

The Sprint Goal was established at Sprint Planning. If this large Product Backlog Item was truly necessary to achieve the Sprint Goal, it should have been pulled into the Sprint at Sprint Planning and not in the last 2 or 3 days of the Sprint. Unless the team is just realizing that this work is necessary to achieve the Sprint Goal, then I don't understand how the team got into this situation.

Basically best thing to do is to try your best to meet Sprint goal while working in a regular cadence, and discuss this story at the Retrospective.

It takes time for teams to master the good Sprint planning and create good Sprint goals without items falling on their head during the sprint to meet the sprint goal, so never take such situation as an emergency which should be solved by any cost(unless it is for external reasons)

I have been here before.  While this may not be the case for you, what it boiled down to was the Developers really wanted to work on that item because it was using some new tech.  It had nothing to do with it being related to the current Sprint Goal.  It was also a way for them avoid working on things like backlog refinement or fixing some small technical debt.  However, the Developers had learned enough about Scrum to know that if they said it was related to the Sprint Goal, they might get away with it. 

I brought it up in the next retrospective because they had 2 days in the previous Sprint to work on it and finished it the morning of the second day of the current Sprint.  I asked them why it was so important that they start working on it early since it could obviously have been done in a single Sprint rather than spreading it across two Sprints.  That was when they admitted it. 

The next time they tried this, I made a deal with them. I told them that we would follow Scrum guidelines and return the item to the Product Backlog at the end of the Sprint if they had not finished and it would be ordered appropriately by the Product Owner.  They agreed, the item was not finished and it returned to the Product Backlog.  It was not ordered high because feedback from the Review made the work unnecessary at the time. 

Let them work on it and use it as an opportunity to learn.  Inspect and adapt with everything.

I see here a couple of issues, which should not be mixed up.

When the PBI is essential for the Sprint goal, the sprint goal needs to be discussed in the retro and maybe the team needs more insights on how to craft a better sprint goal or/and why this PBI has been forgotton to be added during the planning. Especially when the metric for the sprint goal is not well defined and it lets space for too much discussion, then you can trap into the situation that someone come up with "hey, this PBI is also part of the goal".

Carry over are not bad per se. I know this discussion where someone says "Everything in the sprint = commitment = needs to be finished at the end of the sprint". Carry over needs to be discussed when they are part of the sprint goal and if they really needs to be carry over. 

A few things stand out for me…

“carry over”

Just because work is started, it doesn’t mean it automatically continues. There ought to be choice based on Stakeholder feedback, market needs, learning etc. This would really be a PBI that is started and not finished. As Daniel mentioned in his post, this ought to be put back into the backlog for consideration at next Sprint Planning (and not just “carried over”). Consider dropping “carry over” as a term.

“the work they request to be pulled in”

Developers are accountable for the Sprint Backlog (a plan by and for Developers), and no request needs to be made to pull in a PBI to achieve it. If they are calling out that the Sprint Goal is jeopardy with this newly discovered requirement, then scope can be negotiated as others have mentioned.

“So they got through their PBI's but now there is some space”

“Got through their PBIs” is different from achieving the Sprint Goal. If the newly discovered work is a must have for the Sprint Goal, and they cannot complete it in the remaining days, the Sprint Goal is now in jeopardy. Consider focusing on that. Scope can be negotiated with the Product Owner as a first step to determine what can be done to achieve the Sprint Goal.

Any feedback or suggestions on how I get better at handling (or pushing back) on this kind of thing? 

Direct pushing is rather not a good idea, nor does the Scrum Master have any sort of authority to 'rule' the Developers etc...

The SM makes sure that Scrum is established with all its events, and artifacts. Through training, coaching, helping, and facilitation SM is causing everyone to understand Scrum and enabling them to make decisions in accordance with Scrum so that they can keep improving. 

It is of course easier said than done. Anyways, it is better to ask questions than to provide solutions.

You may ask the Scrum Team: 

- What is standing in our way of delivering a Done Increment of Value every Sprint?

- Was our Sprint Goal clear enough or too ambiguous? How to set better goals?

- Are we OK with the current duration of the Sprint? What can we gain or lose if it is longer or shorter?

- Are there any ways we can improve our forecast or better track our progress in the Sprint?

These are obviously very broad examples of a question and knowing the details of your situation you can ask more targeted things. 

Thanks for the replies, these are helpful. Allow me please to clarify what I was asking as I notice there was some confusion? 

Sprint goal agreed

items pulled into sprint

some devs had run out of things to do 

so PO wanted the next high prioirty thing Done

BUT 

Was too large fit into remainign days in Sprint

I suggested this not to be brought in as too large, but team and PO state "but it's somethign we need to work on, we will just carrythe remainder onto the next sprint."

It's not up to the Product Owner to tell the Developers what to work on. The Developers select work for a Sprint and plan how that work gets done. The Product Owner collaborates with the Developers at Sprint Planning, can collaborate with the Developers regarding work that may be discovered during the course of a Sprint, and can keep the Product Backlog ordered so the most important thing is up next. However, the Product Owner cannot tell the Developers what to work on or how to use the time within the Sprint.

I'm struggling with the fact that "some devs" ran out of work. This seems to mean that there is still work that was initially selected for the Sprint that remains undone. Rather than starting new work, I think it would be better to consider how the Developers who finished "their" work can help get this other work to a Done state.

My biggest problem with starting the next highest priority Product Backlog Item, especially when the team says it can't be finished within the Sprint, is that any stakeholder feedback received between now and the next Sprint Planning, especially at the Sprint Review, could make that work less important or urgent for the team to work on. Since it won't be done, the team will have to make the decision to finish the work that is now no longer necessary or carry around undone work as waste.

There's plenty of valuable things that could be done instead, ranging from helping other members of the team get work Done to paying down technical debt to cross-training on new knowledge and skills. These are things that can support the team's current Sprint Goal, make the team stronger and more capable for future Sprints, and not have the risk of waste in the process.