Skip to main content
Enterprise Agile Planning Image

This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.

Last Updated Nov 11, 2008 — Enterprise Agile Planning expert

A Lesson From Open Space — Whatever Happens Is the Only Thing That Could Have

Enterprise Agile Planning

I’ve had the great privilege of learning about Open Space meetings from one of the best practitioners in the business: Diana Larsen. One of the principles of Open Space meetings is that “whatever happens is the only thing that could have.” Assuming that our Scrum team is working in good faith (which is to say, doing the best they possibly can), I believe that this Open Space principle is true for Sprints as well. To that end, I recently responded to a past student of mine who had just experienced a Sprint where a significant portion of the committed content had to be removed from the Sprint Backlog by the end of the Sprint. Here’s how I responded:

So, you’ve hit one of those Sprints where more than the average number of surprises occurred, huh? Well, that was going to happen at one point or another. So my first piece of advice to you is DON’T BLAME YOURSELF OR ANYONE ELSE!

That said, let’s go deeper.

It’s a good idea, during or after the Sprint Retrospective, to investigate what happened a bit further. Dropping a third of your scope is indicative of the introduction of significant unknown risk into the Sprint. However, be careful with your message. The question here is not “what went wrong?” The question you want to ask is “what changed?” Remember, most of the problems that we encounter in building software are not technical, they’re behavioral. So, the root cause you want to pursue will have something to do with something that the team did differently OR a different set of circumstances than they’ve been used to dealing with. So, sure, find out what happened. That’s important. Then, just like with any retrospective, have the team decide what they want to do about it. Do they need to spend more time on backlog grooming? Do they need to spend more time doing design as a team? Were the stories committed to at Sprint Planning too big?

Next, define “success” and “failure” for your organization. Is “success” that the team is producing high quality software and demonstrating slowly improving productivity? Or is “success” actually about getting the number of story points done that you said you would? Conversely, is “failure” producing software that demonstrates significant defects and doesn’t meet the customer’s needs? Or, is “failure” more about not getting the number of story points done that you said you would?

It’s really important that you and your organization are clear about this. If success and failure are pinned down to how many story points you get done, you’re in for a rough ride. Not that it’s OK to commit to one number and then drop a third of your scope every Sprint, don’t get me wrong…but it’s important to realize that, once you and the team figure out what changed, you’ll also discover that the story points your team committed to was actually a lot bigger than they thought. Similarly, if the stories the team got to DONE were re-estimated, you might discover that what they finished was more in line with what the team normally accomplishes each Sprint. So, while asking “what happened?” is an excellent question (and one the team must try to solve), asking “why did you guys fail” is definitely going to be a dysfunctional way to approach this (that is, everyone will simply get defensive – discussion will be about avoiding blame, not real root causes).

If you really feel that the problem lies in the estimation of the stories that were committed to in Sprint Planning (i.e., that they were significantly under estimated), say so during Sprint Review (by the way, a quick way to see this is to review the Sprint Burndown and the hours posted on each task each day). Also, assuming no one on the team slacked off or goofed around during the Sprint and that there were no other significant disruptions during the Sprint, you can clearly show that it’s not an issue of the team doing poor work. If everyone is doing their best, then no other outcome (i.e., completing what the team actually completed) was possible, regardless of the number of points committed to during Sprint Planning. In other words, the focus of ANY conversation about this is not “why didn’t the team get done what they said they would do?” The discussion MUST center around “what happened that caused the stories to NEED to be de-scoped?”

To summarize, my advice is basically that the outcome of the Sprint was the only outcome that was truly possible (assuming the team worked in good faith). The number of points committed to at Sprint Planning might have been attractive at the time, but even then was probably skewed due to insufficient backlog grooming or some other as yet unidentified complication.

Download the PDF version: A Lesson from Open Space blog

More from the Blog

View more
Jul 27, 2021 Becomes First to Achieve FedRAMP Moderate “In Process” Status for Enterprise Agile Planning Solution

Enterprise Agile Planning, the leading AI-driven DevOps value stream delivery, and ma ...
Read More
Jun 21, 2021

How Agile can be implemented effectively across the organization

Enterprise Agile Planning
Just a few decades ago, a “disruption” was seen as an undesirable thin ...
Read More
May 31, 2021

Agile change management processes are key to delivering software faster

Enterprise Agile Planning
With its emphasis on delivery value faster, agile product management s ...
Read More
May 03, 2021

Bringing the agile planning approach to your whole business

Enterprise Agile Planning
The events of the last 12 months have demonstrated that the only sure ...
Read More
Contact Us