What to do with incomplete User Stories

Question

We groomed and planned our sprint to the best of our abilities.

Now the Development Manager, Director, Product Owner, and the rest of the Scrum team would like to review what got Done during the sprint, what didn't get done, and why didn't it get done.

Since this audience will already be present during the Sprint Review, I'm planning on reviewing the above at that time.

Traditionally, we've only reviewed the Done increment in a "demo" fashion.

I'm wanting to keep things positive and avoid people feeling like they need to justify themselves.

What strategies have you employed in reviewing incomplete/untouched User Stories and Tasks?

Answer 1

TL;DR

You may have an X/Y problem. While failure to achieve the Sprint Goal is a problem if it happens often enough, the actual issue you're facing seems to be a lack of trust in the Scrum Team. This is often the result of a lack of process transparency and poor (or at least delayed) ongoing communications with your leadership and/or stakeholders.

The Sprint Review is the wrong Scrum Event to hold this discussion. Regardless of when you hold the discussion, a culture "being held accountable" rather than one of close collaboration and continuous improvement through validated learning will hamper the team's ability to grow and mature.

As the Scrum Master (or whatever your particular agile framework calls your role), you'll need to educate the team, the organization, and the stakeholders on the agile methodology in use, and on the best ways to leverage the agile mechanisms in place to "fail fast" or adapt to unexpected problems. Agility isn't a silver bullet; it just offers more opportunities for adaptation and feedback throughout the development cycle than frameworks based on big, upfront planning.

You may also be missing clear iteration goals or stakeholder collaboration. Alternatively, the team may be suffering from internal or external tasking, rather than outcome-oriented planning and self-organizing behaviors. The team (and the organization) need to solve the underlying process problems, rather than trying to pin blame or transfer responsibility!

Sprint Reviews are not Accountability or Process Improvement Sessions

The Sprint Review is the place to review the work increment. While this can include identifying work not-done, it's not the place to problem-solve for that. The Sprint Review is a reasonable place to discuss problems that were solved, or potential new work that was identified, but it's not the right place to discuss organizational or process impediments. The Scrum Guide says:

The Sprint Review includes the following elements:

• Attendees include the Scrum Team and key stakeholders invited by the Product Owner;
• The Product Owner explains what Product Backlog items have been "Done" and what has not been "Done";
• The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;
• The Development Team demonstrates the work that it has "Done" and answers questions about the Increment;
• The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed);
• The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;
• Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and,
• Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.

The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.

Leverage the Sprint Retrospective

The underlying issue here seems to be a lack of transparency and open communications. This is properly the work of a Sprint Retrospective, which provides the Scrum Team opportunities to:

• Inspect how the last Sprint went with regards to people, relationships, process, and tools;
• Identify and order the major items that went well and potential improvements; and,
• Create a plan for implementing improvements to the way the Scrum Team does its work.

At the next Sprint Retrospective, the team should ask themselves:

1. Why were our estimates off this Sprint?

   • Was there anything we should have done differently?
   • What can the team can do differently next time?

2. Why wasn't at-risk work flagged/escalated/communicated earlier in the Sprint?

   • Was the Sprint Goal at risk? If so, why didn't the Product Owner know before the Sprint Review?
   • If the Product Owner knew, why weren't the stakeholders informed?
   • If the team knew the Sprint could meet its goals, why didn't the Product Owner work with the team to remove scope, or call for an early termination?

3. Why isn't the team engaging senior management or stakeholders when problems arise?

   • Why aren't the Scrum Master and/or Product Owner routinely engaged with the Development Manager and Director?
   • Why isn't the Development Team routinely engaged with users or stakeholders throughout the development process?

4. Why is the daily standup, Kanban board, burndown chart, or other meetings and artifacts not telegraphing blockers or schedule/delivery risk earlier in the process?

   • Why are blockers and risks not being raised at the daily standup sooner in the process?
   • Why doesn't the team feel incentivized to communicate honestly about schedule risks?

The goal of a Sprint Retrospective is process improvement. As the process referee, the Scrum Master must ensure that the team focuses on root cause analysis and actionable process changes, rather than allowing the event to devolve into blaming, kvetching, or hand-waving.

Identify Your Iteration Goals

In Scrum, you must always have a central coherency to provide focus to the Sprint. You can then use the Sprint Goal to focus the team's energy and capacity on the right things. If you're following some other agile methodology, then you still need to find a way to help the team focus on rapid mini-iterations towards the Definition of Done, rather than on just "completing lots of things."

The lack of an overarching goal often drives incomplete iterations, because team members are focused on getting their individual tasks done rather than on completing the gestalt planned for the iteration. This is quite common in organizations that are new to agile principles, or that haven't fully adopted (or mastered) a given agile framework.

In Scrum-like environments, questions like "Why didn't you complete all the things?" is generally code for "We're setting management targets for individual utilization rather than team objectives for each iteration." Real agility comes from systems thinking, self-organizing teams, and continuous process improvement. While mis-estimation crops up frequently in agile implementations, command-and-control tasking and externally-imposed plans are much more likely to be the real problem.

Ensuring that the team has clear iteration goals, and that the team's artifacts and events reflect daily progress towards (or away from) successful completion of those goals, is the essence of agility. If you lack a clear goal, or if the team doesn't evaluate its progress against that goal every single day, most of the benefits of agility will be lost.

Answer 2

Seconding the recommendation not to do this at the sprint review.

I think you have a bit of coaching to do with all involved parties as to the purpose of the sprint review.

After that, I would ask Dev Manager and Director would be, why do they want to know these things? What are they going to do with the information?

I would also coach the scrum team (devs & PO) as to the purpose of the retro, which is to inspect & adapt process. You mention that the devs want to go over this as well, so this could be a reasonable thing to do in a retro: why didn't we get things done? What can we change next sprint to improve our completion rate?

But this kind of question is raised in the retro precisely because management is not around, to help people be fully honest about what went wrong.

It might help to categorize the reasons as "within our control", "within our influence", and "out of our influence". Items in the latter two categories can subsequently be brought up to management, if the team agrees.

Honestly, doing it in this order (first scrum team only, then take selected items to management) is the best way to "keep things positive".

Some groups schedule their retro before their review so they can (if the team agrees) report out any insights or decisions that were made. It sounds like this model might work well for your team.

Answer 3

I would approach it from the other direction.

Under-pack the sprint and have several small stories/tasks ready to go at the top of the backlog. If you complete all the work that you have planned to do, bring something in from the top of the backlog.

That way you will almost always get all the planned stories to 'done'. Return to only reviewing the 'done' stories in the sprint review.

Answer 4

First of all, my strongest recommendation would be: don't. The purpose of the review is to share, discuss, and get feedback on the increment of the product that was complete in order to determine the best work to do next. I would absolutely not dive into why work didn't get done.

The retrospective is there for the Scrum Team to inspect the way it works and that might be a great time to discuss the impediments that prevented the team from completing all of the work they hoped to.

From this, the team may have key learnings that they want to share with the manager and director if there are things that leadership can do in order to improve the environment and allow the team to be more productive.

The fact is that in most organizations, the Director and Manager probably have very little to contribute to that conversations. Their biggest point of value is when the team comes out and says they are stuck with something that is out of their realm of influence and need help addressing it. It is also to share organizational needs and constraints with the team ahead of those conversations. That doesn't mean they are unimportant, just that those conversations aren't really their problems to solve.

Answer 5

I agree with TL;DR that this particular meeting is not the best venue nor time in which to conduct these reviews, but I have no problem at all with managers, directors, owners and other stakeholders wishing to formally review the process. To me it does not imply "distrust."

They're stakeholders. "This is their project, too!"

"Their offices are on the fifth floor." Embrace that perspective. Welcome them to the table, but without sacrificing the integrity of your own internal processes. (And without presuming that they actually intend to interfere.) Their guidance could be "priceless."

Certainly, one of the potential weaknesses of these "self-directed team" project management paradigms is that the team might over- or under-commit; that the team might not be making the most successful decisions; and that there might be any number of reasons why this could be the case. Some of which might be extremely relevant to management outside the team and within their domain of control. Some of which might be apparent to those "outsiders" but not so much to the team. ("If we didn't have confidence in your professional abilities, you wouldn't be here. So, that's not why we want to be involved.")

At more-appropriate times, I think that teams should always be transparent with regards to the decisions that they made, why they made them, and what factors led to those decisions. And, they should always be receptive to guidance and suggestions made by those stakeholders ... without presuming that the presence of such "outside interest" reflects negatively upon anyone. The team, itself, should also be "a team player," always open to suggestion (made in the right time, manner and place), but rightly confident of itself.