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. 🙂
“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.
“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.
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!