I was reminded by a friend's tweet this week about a piece of advice I give in my Scrum talks -- "Don't Lick the Cookie". This is my way of saying, when you're doing Scrum Sprint Planning, don't assign tasks. If you exit your Sprint Planning meeting with a bunch of PBIs and Tasks and those Tasks have someone assigned to them, you've licked the cookie.
In Scrum, you do Sprint Planning to figure out what you're going to do in the Sprint and how you're going to do it. That "how you're going to do it" usually is represented by a scrum board (aka. task board) that has the list of Product Backlog Items (PBIs) and the tasks for each PBI. That's the team's representation of how they think/intend to get to done, working software at the end of the Sprint.
Once per day, the team is going to have a Daily Scrum meeting to determine what their plan is for the next 24 hours and to determine if they're still on-target to deliver that done, working software at the end of the Sprint. Since plans and reality changes the moment you start working, you need to review that plan (inspect) and potentially adjust (adapt) that plan so that you're STILL on-target to deliver the done, working software at the end of the Sprint.
Licked Cookies
So where's this 'licked cookie' thing come in? Let's say that you've got a plate of cookies. They look delicious so you grab one and start eating. You finish that cookie and decide that you want another one. But you find out that, in the interim, someone came through and licked a bunch of cookies. In that rogue cookie-licker's defense, they're licking just the cookies that they fully and honestly intend to eat. Nevertheless, what are the chances of you eating one of those licked cookies? Probably just about zero. Now let's say that it wasn't just that one rogue cookie-licker but instead it's 4 cookie-lickers. They all came through with the best intentions and licked the cookies that they intended to eat. They weren't greedy but at this point, there aren't a whole lot of unlicked cookies so you're pretty low on options for which cookie you're going to eat next.
Back to Scrum. The plan that comes out of the Sprint Planning Meeting is your team's understanding of what you're going to do and how you're going to get to done, working software. That plan is very far from perfect. It's good. It's clear. But it's definitely not perfect. And you will need to adjust it on the fly. You're going to learn new things as you go. Estimates are going to change. New tasks are going to be discovered. Some tasks might become irrelevant and go away. Entire PBIs might go away. Someone might get sick or have a family emergency and become unavailable. Someone else might get pulled away to solve some kind of customer problem or a problem with your live, production servers. Things will change every day. Whether it's your team's understanding of the work or the available people to do that work or some combination of the two -- your plan WILL CHANGE.
Let's say you're working on a 30-day Sprint. If you assigned all those tasks to people during the Sprint Planning Meeting, you're saying as a Team that these are the Tasks and who is going to do them for the next thirty days. By licking the cookies, you're locking yourself in to a single way of getting to done, working software. Those licked cookies are going to limit your ability to change your plan on the fly.
Why is this bad?
Here's an example from a project I worked on. I was the architect / lead developer on this team. For this Sprint, I got assigned the job to design and build the authorization and authentication infrastructure for our application's security system. Oh and also, because I'm a expert at writing database stored procedures, I got assigned to write 10 different stored procedures. The security work was top priority and critical path code for the Sprint. The stored procedures were important but not nearly as complex. There were other people on the team who could write stored procedures but because I could do them much much faster than anyone else, they were assigned to me. I had a whole bunch of licked cookies -- licked security system cookies and licked stored procedure cookies.
Fast-forward a week or two into this sprint and what's happened? Well, that security code is proving to be even more complicated than I thought. What was supposed to be about 60 hours of work has turned in to 90 hours of work (and would eventually turn in to more like 120 hours of work). My team is chugging along and I'm making progress on the security tasks but I'm not clearing those tasks anything close to as fast as we'd estimated. Meanwhile, what's happening to those stored procedure tasks? Well, those licked cookies are still sitting there untouched.
Why are those licked stored procedure cookies sitting there untouched? Because they're licked. They're supposed to be done by me and no one else is picking them up. I was initially assigned those tasks because I could write a stored procedure faster than anyone else on the team. That's true but I'm busy with other stuff and I'm not working on them at all. There are 3 other people on my team who could write those stored procedures. Sure, they'd do it maybe 2x slower than me but at least they'd get done.
It's hard to unlick a cookie.
Why are those cookies staying licked? We're doing Daily Scrums. I'm being honest and transparent about my progress. The rest of the team knows that full well that I'm busy on the security tasks. Why are those stored procedure tasks still assigned to me? Because it's hard to unlick a cookie. Two reasons: 1) it's assigned to me so people just don't even look at them as options for them and 2) there's a lot of emotional overhead required to take those tasks away from me.
The first reason is pretty straightforward. If you're on a team and need something to do, you're going to either work on tasks that have been assigned to you or you're going to take a task that is unassigned. Those licked cookies are mostly invisible to you.
The second reason is A LOT harder. It takes emotional effort to take one of my tasks. You basically have to tell me that I suck at my job. Now I don't actually suck at my job but that's always the fear when you have to confront a person over this kind of thing. (And it is an confrontation.) First you have to point out that I'm half-drowning on the stuff that I'm already working on, that my estimates have been wrong, and that I'm jeopardizing the team's deliverables by hogging those cookies. Then you have to take away my cookies. Whether you realize that this is happening or not, there is DEFINITELY a lot of emotional overhead.
Basically, that's big impediment to adjusting the plan. In Scrum, you want to be able to adjust your plan easily and often. If you have to tackle this overhead of unlicking the cookie a whole bunch of times in your sprint, there's simply no way that that's not costing you time, money, and success.
Why do teams lick cookies?
The biggest reason that teams lick cookies in a Sprint Planning meeting is to make sure that everyone has something to do. That's kind of totally backwards if you think about it. The goal is done, working software. You're trying to bring people to the work (the PBIs) in order to get that done, working software. If you're licking the cookies, you're doing the opposite -- bringing work to the people. The point isn't to keep people busy. The point is to get the features. If you bring work to the people, you're going to do weird stuff like having too many team members or bringing on too much work or planning your work in an awkward way just so people have stuff to do.
The other part of the licked cookie problem is to keep track of what people are doing. You see this more when organizations use some kind of electronic project management system like Team Foundation Server or the Atlassian tools. The team becomes beholden to the needs and desires of the tool instead of the other way around. Remember, you don't have to keep your tools happy. Use your tools to keep your team happy. The tools support the team -- not the other way around.
Now, here's a huge disclaimer. Sometimes teams will have cookies that need to be licked. Usually this is a task that really, truly, and honestly cannot be done by anyone else. That task is critical and it needs to be actively managed and you need to know if it's getting done. In this type of case, I'd say go ahead and definitely assign that task. Lick that cookie. But for most cases, you simply don't need to do pre-assigned tasks.
You don't need to lick your cookies.
If you're doing it right, there's really no need to lick cookies. You've got your plan for your Sprint. You've got a pile of tasks. They're un-licked. You keep revising your plan every day. You update your remaining work (hours) on your tasks. You remove tasks that aren't relevant. You add new tasks to the plan as you discover them. You're working as a team.
In Scrum, you're keeping the team size small so that everyone can understand what's happening on that team. If you're working together as a team, it's just not that hard to know and remember what the team is doing on that day. You're only working one day at a time. And most importantly, you're constantly talking to one another. Not sure if someone's working on something? Ask your team members. Need something to do? Say "I'm going to pick up Task Xyz. Any objections?"
If you're having trouble maintaining situational awareness on your team, start asking yourselves if you're multitasking too much or you've got too much work in progress. If you do less at once, you don't have to work so hard to remember stuff. Pretty soon, you won't be wanting to lick so many cookies.
But we want to lick our cookies.
So let's say that after reading this far, you've decided that you STILL want to assign tasks just so that you can track what everyone is working on. Ok. I get it. That's valid. I don't love it but it's a valid concern. Maybe you're not just one team. Maybe you're a whole bunch of teams working together and you need to have a quick and easy way to 'roll up' status and progress. What do you do?
If you must lick cookies (pre-assign tasks), have a team agreement about cookie licking. I'd suggest two things: 1) only lick cookies that you intend to eat in the next 24 hours and 2) cookies automatically unlick after 24 hours. Put another way, as a team, only do task assignments for the next 24 hours and the team gets to re-evaluate who works on what every day.
Summary
In Scrum, pre-assigned tasks (licked cookies) limit your ability to adapt your plan because the lock you in to who does what. Pre-assigned tasks brings work to the people instead of people to the work. More precisely, pre-assigned tasks assume a fairly rigid plan for how you'll deliver your work as a team and doesn't take into account whether people are actually available to work on a task or not. In the end, I think you probably don't need pre-assigned tasks. So stop licking those cookies!
-Ben
-- Need help getting started with Scrum? Want some training for your teams and Scrum Masters? Looking for a coach to help you sort out why Scrum just doesn't seem to be working? We can help. Drop us a line at info@benday.com or check out our online courses at Pluralsight.com.
