Unfinished works in Sprint

Question

What can we do if we identified in a middle of a sprint that we cannot complete the agreed user stories and Product owner/Business user is resisting to accept the spills / unfinished works? Team might agree to work extra hours but still, we cannot complete the work

Answer 1

This is not an unusual occurrence in Scrum.

We take into a sprint an amount of work that we believe we have the capacity to complete. However, we cannot predict the future and so there will be times when not all the work is finished by the end of the sprint.

There are many reasons for this, including:

• Discovery occurs during the sprint and we realise that the work will take longer than expected
• There are people issues (sickness, team members unavailable, etc.)
• There are technical problems

Because of this, in Scrum we commit to do our best to deliver what we planned to deliver, but we do not commit to always succeed.

What we do try to do though is to learn from our mistakes. In the sprint retrospective we would inspect the sprint and try and determine if there is anything we can do to make our delivery more reliable.

Product owner/Business user is resisting to accept the spills / unfinished works

This is a coaching opportunity. It is for the Scrum Master or agile coach (if you have one) to explain how Scrum works and to highlight that the team will do its best to learn from what has happened.

Answer 2

No matter how hard we try such situations can come up at workplace, team cannot do all of the work planned. In other words team will be able to complete most/some of the work planned.

Discuss with Product/Business which all stories are urgent/important and use the Eisenhower Decision Matrix to bucket the stories. Now let Business/Product choose what they want and have team buy in that whether team will be able to deliver those or not.

Second option is lighten each story by removing requirement points which are in nice to have category but require considerable engineering efforts.

Third option is to get help from other team and reciprocate same in future.

If above options doesn't work discuss the matter with relevant authorities for help on it.

Answer 3

The Product Owner is not your boss.

Scrum advocates a flat hierarchy in the Scrum Team. Each person holds authority over others for their responsibilities and that's it. As per the Scrum Guide, the Product Owner (PO) is responsible for:

• Clearly expressing Product Backlog items;
• Ordering the items in the Product Backlog to best achieve goals and missions;
• Optimizing the value of the work the Development Team performs;
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
• Ensuring the Development Team understands items in the Product Backlog to the level needed.

Notice a trend? The Product Owner is entirely responsible for what gets worked on in what order. S/he is not responsible for how that work gets done, and, correspondingly, has no authority over it. The only tool that Scrum provides to the PO in determining when a Story is completed is prioritization.

Scrum advocates time-boxed, sustainable work.

The inescapable fact is that a non-zero amount of work can only be completed in a non-zero amount of time. While efficiencies and inefficiencies can skew this, in general, the more work that needs to be done, the longer it will take. Scrum accepts the reality that infinite work cannot fit in finite time. To increase the long-term throughput, it advocates a sustainable pace. To increase the accuracy of estimates, it provides the time-boxed Sprint.