Clayton Lengel-Zigich: Welcome to another episode of the Agile weekly podcast. I am Clayton Lengel-Zigich.

Roy VandeWater: I’m Roy VandeWater.

Failing A Sprint

Clayton: Today we’re going to be talking about a very rare thing that we’ve heard about from certain people. It’s called, “What happens when you fail your sprint.”

Roy: I’ve never experienced this personally.

Clayton: Me either. Of course not.

Roy: Right. Hypothetically, if it did happen, what do you do?

What Constitutes Failing A Sprint

Clayton: I guess we should define it first. Roy and I were talking about this topic earlier today and I was thinking, “I wonder if we think the same thing ‑‑ what it means if we say ‘fail a sprint’”? Is failing a Sprint the same thing as, you committed to do five stories, and you only got four done? Are we calling that a failure?

Roy: Yeah.

What About The Sprint Goal

Clayton: OK, I think so, too. What if you committed to doing five stories and then, you also had a sprint goal and you fulfilled the sprint goal, but you didn’t do one of the stories? Is that a failure?

Roy: That’s interesting. I haven’t really made sprint goals all that often, which is probably a bigger problem, but that’s an interesting point. If the value of the sprint is to achieve your sprint goal and your stories are almost an implementation to try to achieve that goal, then maybe achieving the sprint goal is all you need.

Clayton: For example, I always like to use the travel website. If our sprint goal is to make it easier for people to book a rental car when they book a cruise vacation, and we fulfill our sprint goal, but we didn’t do one of the stories, does it really matter?

Roy: I think that one is a little bit in our sync, because making it easier is like a slighter scale. You can make it a teeny, teeny little bit easier by doing a text change. I think the important part…I think what I really consider a failure is when you promise to deliver something and you fail to keep your promise. When essentially, you lose trust with the people that you have promised to, because you didn’t do what you said you were going to do.

Clayton: Like maybe, the product owner. You say, “Hey product owner, leave me alone for the next week and I promise you that I will get this thing done.” Then, in a week, you don’t get it done. So now the product owner trusts you less.

Roy: Right, exactly.

Not Doing What You Say You Are Going To Do

Clayton: OK. I think that makes sense. If we define failure as making a promise and then not…basically, we’re saying you aren’t doing what you said you were going to do. We talk about that, we use that phrase a lot internally. If you say that sprint failure is not doing what you said you were going to do, a lot of people I know don’t like to talk about sprint failure because they don’t like to talk about failing.

Roy: Well, it’s confrontational, of a sort.

Explaining Away The Failure

Clayton: I see a lot of people, a lot of teams that will try to find all kinds of ways to explain why they didn’t really fail. Whether it’s, “Well we were working on these five things, but then something happened and we didn’t have to this anymore, so we didn’t really technically fail because we still did the important stuff.”

Roy: Or “We worked on all of these things, but then this major interruption happened or this outside dependency caused us to fail our sprint because we were waiting to get something back from them. We thought we’d get it this week and we didn’t.”

Using Failure As A Mechanism To Learn

Clayton: One thing I’ve always noticed or thought, personally, is that if you don’t view failure as that big of a deal, if you view it as a learning moment, or a way that you can improve, then it doesn’t really matter if you failed because who cares, you don’t have to try to explain it away.

Roy: As long as you’re honest about it, you try to fix it for the next time.

Clayton: Let’s describe that then. I think there was a team that you were working with or we were talking about that had failed their sprint, or they weren’t going to get it done on time. So they cancelled their demo.

Roy: They actually postponed their demo about three or four days under the idea of, “We don’t have anything to demo right now because we didn’t do the stories we said we were going to do, but we should have them done in three days so we’re going to go ahead and do the demo then.

Clayton: In the entire sprint review we include the demo and the retrospective. Did they do the retrospective or did they skip that part too?

Roy: No, as far as I know the iteration was essentially extended for an additional three days.

Partially Done, Should We Demo It

Clayton: In that case we would call that a failure because they didn’t get it done when they said they’d get it done. What advice would you give to a team that doesn’t get things done? Maybe they got 80 percent of their stories done. Let’s say that rather than being really bad and getting 80 percent of everything done, they actually got eight out of ten stories done. Would you suggest that they show something in the demo? How would they handle that in the demo? What would the team do?

Roy: I would say that if you actually complete something, then show it off because it’s going to go into production, but if you haven’t finished it don’t show it because when you’re demoing, you’re demoing to not just a product owner who knows what’s going on within the team and was probably made aware way before this that not everything was going to get done, but you’re also demoing to the stakeholders, potentially even users of the system and so I feel it’s important to actually show them what they are now able to have.

Clayton: So those are the things you only demo what you’ve actually shipped.

Roy: Exactly.

Clayton: I have always gone back and forth on showing things that aren’t done‑done or unaccepted, only for the sake of maybe really valuing extra feedback. I guess there are probably more bad behaviors that come from demoing half done things or not done things then you’d get a benefit from the feedback.

Roy: I’m on the fence on that too. On one hand I think you shouldn’t demo anything that isn’t done because you are setting this expectation that features part of the product when you are starting a new moderation and it may not be prioritized anymore because something may have come up. The specific details on how to post a function may completely change. Essentially you are demonstrating something that may never happen so you are setting expectations that you don’t have the power to meet.

However, gaining additional feedback totally makes sense ‑‑ that may be what drives the actual change so it’s really dangerous I feel, but if you were to be extremely explicit about the fact that this is not finished, there is no promise, you are doing it purely to receive feedback, I could see that it might be OK.

Clayton: So probably don’t ever do that because most people are not going to listen to you when you say you are not going to get this.

Roy: I could see tens of people attending the meeting and be, “Wow”! And then selling to all the customers and then it gets put on the back and it’s never going to get done. Then you are taking power away from the product all of a sudden cause now they have to finish it because all the customers are demanding it.

Disclosing Sprint Failure

Clayton: In a crucial demo part of this review, some people from the team might actually get up and showcase their features and show them on a projector screen. How do you think the team should address the sprint itself ‑‑ should they address the fact that they didn’t get it all done or should they skip over that?

Roy: It is important to be as transparent as possible. If a team has failed a sprint, totally own up to it. Explain why but be really careful that you are explaining why and not making excuses. I would recommend verbalizing all reasons things specifically the team did wrong. The example I made earlier where you are depending on an outside source and they weren’t able to get you the stuff you needed on time and you thought they would. I would word that as “We made a promise for things that we did not have direct control over and the way we would mitigate that in future is by only promising things we know we can deliver.”

Clayton: I was watching a video from Dan North speaking in the conference about high performing teams. One of the things I thought was really interesting was he was talking about the team he was working on ‑‑ which was really high performing. They had a component of their showcase, they were doing scrum, but the component of the demo where