Share →
Buffer

I may have done a dangerous thing. I wanted to show teams how to commit a two-week sprint in half an hour… and then we did it in fifteen minutes.

A few months ago, I wrote about using The One Thing to corral your daily standup and focus on the question that matters.

It turns out, the sprint planning meeting—another activity many teams find painful—has a one thing, too. Imagine how powerful and efficient your teams could be if they knew how to clear away the distractions and get on with it.

Get your meetings right

Conventional Scrum wisdom calls for a four-hour timebox on planning for a two-week sprint. As we know, a timebox is a maximum. If you can get it done in less time, you should. In my dev days, my team and I ran planning in about two hours for a two-week sprint, and we found it excruciating. I cannot imagine taking twice as long!

I’m working with a team who felt that their planning and pre-planning was getting away from them: they were spending nearly two days (!) altogether, yet didn’t have a strong track record of completing the work in two weeks. It didn’t smell right, and they wanted to figure out what to do. (Or, as we discovered, what to stop doing.)

Why does it matter? Just like the bad standup, bad planning is an existential threat to agility.

Before you begin, skip the beginning

Sprint planning starts with a prioritized, order-optimized backlog containing 1-2 sprints’ worth of items that the team is basically familiar with and agrees are ready. The Scrum.org guideline for achieving this is another timebox: about 10% of the team’s and 30% of the product owner’s time in the preceding sprint. It’s up to the team how they want to structure the time. Independent study, small breakout sessions, or a single team pre-planning meeting are all reasonable.

However, in my sprint planning demonstration, I cheated. I knew my team did their pre-planning in one big meeting… and I knew they hadn’t held it yet. A perfect time to show them what they could achieve without it.

A small, safe-to-fail experiment

The team and I got together around a lunch table. No laptops, no TFS, no whiteboard, no planning poker deck, they didn’t know what I was going to spring on them so they hadn’t even brought any notes or user story writeups with them. Just themselves, who—I knew from attending their retrospective a few days earlier, and this fact is critical—knew how to work together and trusted each other.

We started out talking about long meetings and planning time, and I reiterated the same agile/lean principles I’d recently taught them in class: embrace variability; take risks instead of trying to avoid them or talk them to death. They’d heard me say that a well-managed failure is nearly always the fastest, cheapest, and most accurate way to resolve an unknown, better than any “investigation” they could possibly do. I hadn’t sold them on it yet.

“That sounds nice,” they said, “but we just can’t commit work into our iteration until we know how long it’s going to take, and we can’t know how long it’s going to take until we know how we’re going to implement it, and that usually requires some looking into the code as well!”

So I stepped off the soapbox and into the firing line. “OK, let’s test that assumption. Let’s try something different, right now. What do you say?”

They were puzzled, but game. Love this team. 🙂

Lightning round

“What’s the top item on your backlog at the moment? Not that ugly one you punted out of the last planning, that one isn’t ready. What’s the next one after that?”

They all looked at Céline, their product owner.

“Umm… user list page.”

“Do you all basically know what user list page is? You’ve heard of it?” Nodding. “OK, a new sprint is always a clean slate. So this is the only story you’ve got right now, and it’s your top priority, right? So let’s agree that you’re all going to focus on this story, and only this story, and you’re all going to pitch in in whatever way you can until it’s done. Can you count on each other to do that?” They looked at each other and nodded again.

“Great. So, given all of that, can you give me a fist-to-five on how confident you are that you, as a team, working together, could complete user list page from start to finish, including test, within two weeks?”

The team looked a bit like deer in headlights for a moment.

“But we don’t know—”

“I know you don’t know. That’s why I’m not asking you to commit, I’m asking you how confident you are. Knowing only whatever you know right now. Yes, I’m serious, put those hands up.”

4, 3, 3, 4, 2, 1.

Confidence and doubt

“Great! You threes and above, you’re confident enough for the moment. Let’s focus on our coders, who not suprisingly aren’t. Antonios and Chau, can you talk to us about why you’re a two and a one?”

They both said, kind of at once, “I don’t know what the requirements are!”

“Fair enough. But you said you know what user list page basically is, right? You just don’t know the details?”

“Right, but that isn’t enough to code from. We need to know what the stakeholders want it to do!”

At this point, a lot of teams will engage in discussion about the acceptance criteria. That’s often a reasonable practice, but in my exercise I really wanted to illustrate that what this team viewed as essential up-front planning truly can be moved out of the planning meeting and into the sprint. So I pushed it.

“Sure, there are things you’ll need to know before you can implement. But remember, we agreed that the entire team will make this story their top priority. What if the first thing you do in your sprint is sit down with Céline and have her tell you everything she knows about the requirements? If that’s what you need from her, she’ll do it.”

They looked startled, even Céline, but I could see a few eyebrows raising.

“Antonios, does that change your confidence?”

“I guess I could go up from a two to a three.”

“Hey, a three is good enough for now. Chau, what about you?”

“I’d say I can go up to a two.”

“OK, a two still isn’t confident enough. Can you tell us more about what’s got you concerned?”

“Well, what if we commit and then Céline tells us a bunch of requirements that we can’t get done in two weeks?”

Value for cost

This time it wasn’t me. Céline must have been thinking about user list page, because she jumped in.

“The user list page shouldn’t take us more than two weeks to build. If it does, our stakeholders aren’t going to feel they’re getting proper value for cost! It was never meant to be fancy. If you tell me you can’t do it in two weeks, then let’s find a way to cut scope and deliver something less expensive. I’ll have the stakeholders prioritize the nice-to-haves for a future sprint.”

It’s a good thing we were sitting in a booth. I think if the team had been on chairs they might have fallen off of them.

“Chau, now that you know Céline is happy to negotiate scope with all of you to make sure it can get done in two weeks, how confident are you that you can do it in two weeks?” Leave it to a developer to be asked that question and still only give me a three! But there it was. “Team, how about you?”

5, 4, 4, 5, 3, 3.

When you agree, stop talking

“That’s it. You’re all confident enough. You can commit to doing user list page in the next sprint, and—this is the best part—because you all agree, you don’t need to discuss it any more. When you agree, stop talking! Now, what’s the next story on your backlog?”

They groaned. “Group list page.”

“This time, we have to take into consideration that you’ve already committed to user list page. So, how confident are you, knowing what you know now, that working together as a team you’d be able to fully deliver both user list page and group list page in the next sprint?”

3, 2, 1, 1, 2, and a fist.

“Looks like you agree that you’re not confident!” They laughed. “So don’t commit to it. And that’s it. You’re done planning. When you get to a point that you’re not confident, stop looking at new work. Just take what you’ve committed so far and get on with it. If you get done early, you can always reconvene and commit to something new—and as we’ve just demonstrated, that won’t take hardly any time, so you don’t have to worry about doing it more often.”

“There’s a couple of much smaller stories on the backlog behind group list page. Those might fit. Could we look at those?”

“Céline, you’re the product owner. What do you think?”

“Of course. Our stakeholders would love to see those delivered.”

“Great! Just use the same quick fist-to-five technique so you can tell very quickly whether they’re worth talking about before you invest time discussing them.”

Velocity vs. planning

Antonios had been thinking through something, and finally he spoke up. “If we talk about committing just one story at a time in isolation, this might be fine, but I feel like we’re missing something. It isn’t going to be good enough to only do one story per sprint. We’ve got a release coming up, and there are things we wanted to get into it, and we can’t meet our goal at this pace.”

“Antonios, you’re exactly right. That’s a great observation. You and the team should absolutely talk about continuously improving your delivery. Remember when I said a meeting has one purpose, and to make that meeting effective and efficient you need to focus on that one purpose only? It isn’t the purpose of the sprint planning to address your team’s overall velocity. And I worry that if you did, you’d pressure yourselves to take on more work than you should, which would make you less likely to get any of it done. But there is a great meeting where you and the team could all look at your velocity and talk about ways to improve it, and that’s your retrospective. That’s what it’s for.”

They paused to take that all in. We’d just planned their next sprint in under half an hour, with no breakdowns and no estimation, and they felt like they could get it done together, and it all seemed so crazy it just might work.

Scaling it out

A day or two later, we held a lunch-and-learn session with this team and three others, where the question on everybody’s minds was finding the right balance of time spent on pre-planning and sprint planning. This time I was ready, and after some soapboxy slides on variability and risk, I dove into a demonstration for the room.

“Shall we try an experiment? Ai Vee, can you tell me what’s at the top of your backlog at the moment? Ai Vee’s team, are you all basically familiar with that story? OK, give me a fist-to-five on the question…”

And away we went.

Planning Assertion

“See, I told you it’s possible in under an hour, and here we’ve spent, what, not even half that?” I couldn’t see a clock from where I was. That’s when the teams told me we’d done it in under fifteen minutes.

Safety check

Lightning Sprint Planning Theater™ was created to counter an entrenched bad habit—big up-front planning—in teams who don’t know how to get along without it. It’s intentionally extreme! The purpose of the exercise is to demonstrate, and help teams really feel, the following:

The goal of sprint planning is confidence, not certainty. The big lie of up-front planning is that it reduces wrongness. It doesn’t. It’s safer to expect and manage the risk than to try to plan it away. As a bonus, it’s fast, cheap, and more responsive.

Don’t use estimates to drive commitment. The big lie of estimation is that it drives better decisions. It doesn’t. A qualified team’s informed instinct will be more accurate than estimation. As a bonus, it’s fast, cheap, and empowering.

Is there no place for estimation on a healthy agile team? That’s a different discussion. My argument here is that the sprint planning is for committing, and estimates are not needed for a commitment. Beyond the sprint planning meeting, I’m newly following #NoEstimates; excited to hear from great minds who’ve explored this more deeply than I have so far. I’m mulling over another blog post about using estimation after commitment and after delivery, to create meaningful metrics that help a team retrospect and grow.

Are you ready to commit your sprint without all the fuss? Can your teams trust themselves and each other enough to listen to their instincts? How have you solved the planning challenge in an agile way? Let’s hear from you!

Print Friendly
Tagged with →  
  • Rik D’huyvetters

    Great blogpost.
    I love the idea of #NoEstimates *inside* the scrum team, but it is next to impossible to get management on board.
    So outside the team I still use estimates to get a grip on the expected costs and timing of the project, and use the sprint metrics (velocity) to compare the estimates to the laws of physics.
    It is overhead, but it is an overhead that can be managed by someone outside the team (projectmanager).

  • Charles Bradley, Scrum Coach

    Sharon,

    Several things bother me about your post, so I’ll just focus on the more important ones. There is a lot of talk about ‘commit’. The Scrum Guide changed two years ago to say “forecast” instead of “commit” for a very good reason. This has large implications, and it troubles me that you are not up to date on that new terminology.

    Second, it seems like you encouraged the team to do product backlog refinement (as it is now called in Scrum) inside the sprint, when the whole purpose of the practice is to get items “Ready” for the upcoming Sprints — to encourage efficiency and understanding, and discourage delays. The reason backlog refinement is a required activity in Scrum now, is to avoid the exact thing that you coached your team to do.

    Third, you say this was an experiment, but you fail to report the results, so your article seems to have a hole that a truck could drive through. What was the result of the experiment?

    As an aside, the forum where I saw the link to your post described your technique as a “Sprint Planning Hack”. I just thought you should know that.

  • Rik, great point. What you’re describing is basically water-scrum-fall: when your implementation teams are practicing agile as best they can, but the rest of the organization isn’t on board. This creates friction at the points where teams—doing agile—and everybody else—still thinking waterfall—have to interact.

    Using the Scrum master or another servant leader to navigate that interface and protect the team is a great stopgap measure.

    I wouldn’t stop there, though. Estimates are just as wrong for the business as they are for the team, for the same reason. A water-scrum-fall organization can’t achieve continuous delivery and can’t realize the competitive and client-delighting advantages of enterprise agility. Educating those outside the team and those outside the tech realm is essential in the long term.

  • bsktcase

    Rik, great point. What you’re describing is basically water-scrum-fall: when your implementation teams are practicing agile as best they can, but the rest of the organization isn’t on board. This creates friction at the points where teams—doing agile—and everybody else—still thinking waterfall—have to interact.

    Using the scrum master or another servant leader to navigate that interface and protect the team is a great stopgap measure.

    I wouldn’t stop there, though. Estimates are just as wrong for the business as they are for the team, for the same reason. A water-scrum-fall organization can’t achieve continuous delivery and can’t realize the competitive and client-delighting advantages of enterprise agility. Educating those outside the team and those outside the tech realm is essential in the long term.

  • Steven Gordon

    Interesting approach.

    Looks like a first step towards Kanban – just take the highest priority story and make it work.

    My main problem with the flow here is at what point does the team get to say “the user list page story should be sliced”? If the team devotes the majority of the sprint to this single story (just enough left over time to do a few small back burner stories), that seems like too much risk, especially when what the users really want may not be so clear.

    Instead of the PO offering to cut scope to make it fit within 2 weeks, if the PO works with the team do define a thin slice that takes a much smaller fraction of the team’s capacity yet provides the actual users something to give concrete feedback on, then risk is reduced. If it turns out to not be what the users want, you have wasted much less capacity finding out. If it is right on, there is still the possibility that when real users see it, they will have good ideas on what should be added on to achieve maximum bang-for-buck. Agile is about leveraging feedback!

    Also, this allows the team do to a first thin slice for that dreaded “group list page” story. This advances the feedback to figure out what that story should really be. Pushing it just creates the situation where there is pressure to fit all of it in another 2-week sprint instead of getting feedback on slices.

    Slicing stories thinly is a much more valuable use of collaborative planning time than estimating how many hours each little subtask is going to take.

  • bsktcase

    Hi Charles! Great information in your comment – thanks for sharing your perspective!

    I think I can save us both a bunch of time. Ken Schwaber says if you don’t do Scrum by the book, then you’re not doing Scrum. So, my teams and I aren’t doing Scrum. 🙂

    Having said that, yes, I’m familiar with Scrum.org’s recent updates! I don’t care for either “commitment” or “forecast” actually; I slightly prefer “refinement” to “grooming” (this team calls it “pre-planning”). As I’m not beholden to a certifying organization, I choose words my teams and readers are more likely to find familiar. (I still have the possibly bad habit of calling them “sprints” even when my teams call them “iterations”.)

    While we’re on the subject of word precision, my name isn’t Sharon. 🙂

    Regarding Readiness, you are exactly right, and I didn’t explain that in this post nearly as well as I could have. It’s barely mentioned, in passing, at the very beginning of the first exercise, when the team didn’t vote on or discuss the top story on the backlog because it wasn’t ready. The team’s confidence vote can also function as a referendum on Readiness. I asked Antonios whether he believed he could get the information he needed from Céline during the sprint: in this case he genuinely felt he could, and he agreed that the answers he was waiting for wouldn’t affect the simple boolean of whether the item could be done in two weeks. (It didn’t make the edit cut, but we did talk about it.) He might have said instead that it wouldn’t be enough for him to feel confident in committing. If he had, the team would have needed to make a different decision (e.g., break down the item, or send it back for clarification). That’s sort of implied by the fact that while Antonios was persuaded, Chau wasn’t. But, you are right, I didn’t illustrate it effectively, and your feedback on that point is very helpful indeed.

    As to the experiment, the scope of this one was pretty narrow: to see whether the team could feel confident about committing to work without estimating it. They reached the end of the exercise having committed to work without estimating it, and they agreed that they felt confident. In that sense, the experiment was successful.

    Of course, a more meaningful goal would be to see whether this technique yields as-good-or-better delivery compared to sprints in which teams take a longer time and/or rely on estimates to plan and commit. As I mentioned in the introduction, this team has been using canonical sprint planning, and their devotion to up-front analysis, long meetings, and detailed estimation has NOT resulted in reliable delivery. They haven’t been using this technique long enough to know whether it helps or hurts. I will definitely report back updates!

    “Sprint Planning Hack” is awesome! 🙂 Thanks again!

  • bsktcase

    Steven, I love this perspective. Yes, you’re exactly right that smaller stories are also needed. If they don’t get a handle on reducing batch/item size, then they’ll still struggle to deliver and cute short meetings won’t fix it.

    I haven’t had any luck teaching the thin slice/”carpaccio” model, but I think this team is starting to warm up to Minimum Viable Product. Even in this story, they were shocked to find that Céline and their stakeholders could be willing to accept an MVP smaller than the original “desirement”. It felt like progress, though they have a ways to go yet. 🙂

    Thanks for this!