Scrum fall through tickets - How to handle them?

@Ayesha Tarrannum, If meeting the Sprint A Goal A was paramount, why did the team miss it? What did the Scrum Team do to find the root cause? Once that is established, is Sprint A Goal A still more important that Sprint B Goal B? What does the PO and stakeholders have to say about it? Perhaps that will guide your next Sprint Planning.

Does that help?

A few thoughts:

You have planned for an upcoming sprint that is Sprint B with Goal B

All that you have at that point is a "plan".   In fact, nothing is determined until the Sprint Planning event for that sprint.

By the end of Sprint A, you realized there are some undone tickets that satisfy Goal A which will take 1 week of time to be DONE

Was the Sprint Goal for sprint A achieved?   If not, has the team discussed the possible causes for missing the Sprint Goal, and ways to improve reaching future Sprint Goals?   Perfect Retrospective discussions.

And if the team failed to meet the Goal A in Sprint A, why is there any level of confidence around a 1-week estimate to wrap up Goal A?

Create a new sprint with all those fall through tickets and still have Goal A achieved?

You should never alter your sprint cadence to account for missed Sprint Goals   Never.

You are planning for Sprint B.   What is the most important thing for the Development Team to deliver in the upcoming sprint?   Answer the question "Why are we sprinting?"

Thank you very much for your response, Steve and Timothy. 

We know the answers to why the sprint failed in delivering the goal and lets say it was agreed in the sprint review that Sprint A goal is still important to achieve than Sprint B. what next? How do we account for that fall through. Say you forecast the work to finish in 1 week.  How do you handle this? 

@Ayesha Tarrannum, The Sprint didn't fail to deliver, the Scrum Team failed. 

Okay, so meeting the Sprint A Goal A is still important, and you're saying it may take approximately a week to finish. What's the problem then? You've already handled it right?

How do we account for that fall through

Are you sure there is any so-called “fall through” at all? Isn’t it a matter of inspection and adaptation?

In this case, wouldn’t the team improve its practices to better achieve future Sprint Goals, and re-estimate any valuable remaining work on the Product Backlog?

The history of Sprint A is relevant for understanding what lessons can be learned. It's also a valuable insight that might help the Development Team forecast more effectively.

But once it comes to Sprint Planning for Sprint B, the inputs are pretty simple. There is an existing Increment, and a Product Backlog (which may or may not contain work that wasn't "Done" in Sprint A).

Just like with any sprint, the Scrum Team should then choose the appropriate Sprint Goal based on the current situation, and what it aims to achieve during the sprint.

There is nothing that says the team cannot formulate a Sprint Goal that means achieving two things, other than the Scrum Value of focus.

To be clear, the word "and" can appear within a Sprint Goal, and I would favour setting such a goal if it reflects the genuine aims and expectations of the Scrum Team; but it can also be a risk, and may indicate that things are not functioning effectively.

There is nothing that says the team cannot formulate a Sprint Goal that means achieving two things, other than the Scrum Value of focus.

@Simon Mayer, Just to make sure that I understood this correctly, you're saying that it is okay to have more than one goal for the Sprint which may equate to accomplishing 2 things for that Sprint? Just to be clear, I am associating accomplishing two things as accomplishing two goals.

It is actually an interesting subject of conversation because if the Development Team can still be focussed enough to achieve it, and Scrum doesn't say anything against it other than the Development Team not losing focus, then is it okay to have more than one goal for the same Sprint? I think the reason why multiple goals are not recommended are because, one to prevent the loss of focus, and two, to ensure that the whole team is committed towards the same goal.

I am curious to see what others think of the same scenario.

I'm not saying that the team should aim to achieve two separate things; just merely that they could and it might be the right approach.

I would suggest viewing it as a single Sprint Goal with two elements, rather than two separate goals. It may seem like semantics, but if the team considers it has two goals to achieve, it might trigger unhelpful behaviours, such as team members focusing on separate goals without considering how they tie together.

To underpin Simon's point, there is nothing specifically in the Scrum Guide that keeps you from having 2 goals. However, the Scrum Value Focus has you think about what would be the downside of this. To put this into a more practical example; the company I'm assigned at still forces a separation between "Functional"(design and architecture)  and software, leading into a split in teams, ultimately having a group of individuals instead of actual teams. These split teams have split Sprint Goals, too.

So assess what risks there are working with multiple Sprint Goals.

I'm going to ask the first question that came to my mind that everyone else seems to be overlooking.

Imagine you are currently working on Sprint A with Goal A

You have planned for an upcoming sprint that is Sprint B with Goal B 

By the end of Sprint A, you realized there are some undone tickets that satisfy Goal A which will take 1 week of time to be DONE and assuming these are still very high priority tickets. 

So the team has already planned Sprint B before Sprint A is finished? How can you do this since the previous increment, the feedback received from the stakeholders in the Sprint Review and result of Sprint Retrospective are all parts of the information used for Sprint Planning. You have planned with incomplete information so you really can't assume that the plan is ready to execute against.

As many have said, this isn't fall over work. This is information that needs to be inspected, Product Backlog adapted and the next Sprint forecast prepared using all of the information gathered from your previous iteration. 

A warning from my past experience, if a Scrum Team starts planning Sprints while the current Sprint is still in progress there is a tendency to want to do 2 or 3 ahead.  Which is basically setting yourself up for waterfall process and you do not gain all of the benefits of agile.  

To be clear, the word "and" can appear within a Sprint Goal, and I would favour setting such a goal if it reflects the genuine aims and expectations of the Scrum Team; but it can also be a risk, and may indicate that things are not functioning effectively.

For me, the use of the word "and" in a Sprint Goal is a red flag that introduces the following risks:

• Extra communication and setting of expectations may be required to support conjoined Sprint Goal initiatives
• A team's "focus" around inspection and adaptation can be impacted by the inclusion of multiple Sprint Goal "initiatives"
• A team may have to deal with the unenviable position of meeting only "part" of their Sprint Goal.   did the team meet their Sprint Goal, or did they miss it?   Is the sprint a success, or a failure?

 I think this is what I would do 

1) check the priority of leftovers from sprint A against what is in sprint B . And adjust your sprint B if needed . 

2. Retro : root cause of such a situation of not completing such high priority tasks ( don’t panic or react or stress as there might be very acceptable reasons and stress has much more domino effect that sometime we can think of ) 

I fully agree with all comments and discussion above re. pro & cons of one or more sprint goals or more elements within same sprint goal.

Just one thing I feel it remained not fully answered / explained (@Ayesha question). Sprint A Goal A was not achieved, they forecast 1 week needed for completion of Goal A and should have higher priority than Goal B. At retrospective reasons behind not achieving Goal A should be assessed - inspection & adaptation.

Suppose (even though not mentioned) Sprint length is 1 month which should be consistent throughout development inspected and adapted but not changed too often. Undone items in Sprint A re estimated and prioritised at top of Product backlog (no additions by Stakeholder / PO during Sprint review). Only those undone items from Sprint A form a coherence and sensible Sprint goal. Any additional PBI's selected from PB by Development team during Sprint planning would make Development team to work on separate initiatives.

How would you approach this situation?

Changing Sprint length just for this to finish undone items from Sprint A would not be consistent! Adding additional PBI's would result in lost focus and as prescribed by Scrum Guide result by DT not working together.       

Where should a red line be drawn? How much coherent should two / three elements within one Sprint Goal or two Sprint Goal be, to be considered to cause DT to work together?

In my opinion, DT after inspection and adaptation during Sprint Retrospective where previous estimates should be revisited and possibly adapted, should during Sprint Review take undone PBI from previous Sprint from PB + new PBI (sliced in tiny pieces if needed to be as coherent as possible) that would keep them focus for the rest of Sprint B (3 weeks) and make them work together. At subsequent review both achievements presented.

Would this be an adequate approach in your opinion? Question that comes to my mind, input to Sprint planning as prescribed by Scrum guide, latest product increment would be missing i.e. Goal A not achieved but if achievement of Goal A and subsequent increment is expected and envisioned (only one week left) than proceeding this way should be ok or! 

thank you       

"they forecast 1 week needed for completion of Goal A"

"achievement of Goal A and subsequent increment is expected and envisioned (only one week left)"

Just to confirm, these statements are relying on an estimate provided by whom?   The Development Team?   

It is always recommended that any valid estimate originate from those doing the work.   However, we have a Development Team that did a poor job estimating work in Sprint A.   What are we basing our confidence on that undone work from Sprint A will only take 1 more week to complete?

In my opinion, the estimate provided by the Dev Team around the remaining Sprint A work is irrelevant.   

The only consideration when planning Sprint B is what is the most valuable functionality (Sprint Goal) that the Development Team can deliver?   Everything starts with that identification, and then the Dev Team can assess (based on their capacity, skill, and productivity) what they may be able to complete in the next sprint.

I'd like to thank everyone for their valuable time. 

@Ian: to your questions " re you sure there is any so-called “fall through” at all? Isn’t it a matter of inspection and adaptation?

In this case, wouldn’t the team improve its practices to better achieve future Sprint Goals, and re-estimate any valuable remaining work on the Product Backlog? "

I am in 100% in agreement with respect to "inspect and adapt" and all the points you mentioned. but still - the question that remains open is"what next?"-  how do we address the tickets that weren't completed in Sprint A? Is compromising the cadence the only way?  

@Timothy: Based on the lessons learnt, team anticipated the tickets to be less complex than what they started off with in Sprint A.

I also agree that Sprint B is worthless but it was created by PO with all good intentions. None of the team members have invested any of their time in Sprint B except maybe 5%-8% during refinement meetings. 

I am in 100% in agreement with respect to "inspect and adapt" and all the points you mentioned. but still - the question that remains open is"what next?"-  how do we address the tickets that weren't completed in Sprint A? Is compromising the cadence the only way?  

 

@Ayesha, you are not explaining what you mean by how do we address the tickets? 

 

If you still need to complete the work that is in these “incomplete tickets” from Sprint A, the logical next step would be to add it to the Product Backlog, and plan that work for the next Sprint if it is still deemed valuable to pursue.

Can you explain why you feel that changing the cadence is the only solution? How does that help?

@ Timothy: I do agree they are just estimates. They are made by DT. I do agree they missed estimations in Sprint A (probably their first Sprint) - that's why I mentioned that estimation in Retrospective should be first inspected and adapted, so one would expect that they are more closer to reality in future. 

"The only consideration when planning Sprint B is what is the most valuable functionality (Sprint Goal) that the Development Team can deliver?   Everything starts with that identification, and then the Dev Team can assess (based on their capacity, skill, and productivity) what they may be able to complete in the next sprint."

I do agree with this. But as I mentioned what if:

Suppose (even though not mentioned) Sprint length is 1 month which should be consistent throughout development inspected and adapted but not changed too often. Undone items in Sprint A re estimated and prioritised at top of Product backlog (no additions by Stakeholder / PO during Sprint review). Only those undone items from Sprint A form a coherence and sensible Sprint goal. Any additional PBI's selected from PB by Development team during Sprint planning would make Development team to work on separate initiatives.

How would you approach this situation and you are pretty confident you can finish leftovers from Sprint A in 7/10 days?