Agile Project Management: Estimating Project Size Part 2

• Use Relative Sizes - If you can help it, never estimate how long something will take to get done. We can hold that off for part 3. For now, just figure out how tough each thing is to deliver compared to the other things. That's called relative size, or relative complexity. There are lots of reasons that relative size beats duration estimates. The one I like the most is that relative size asks is a much more easy question to ask than how long something is going to take to deliver. This means it's easier to accomplish. It also means that you can do the part about delivery in a separate step. Remember: lots of little, easy things instead of one big complicated thing.
• Beware of Anchoring - the human mind can only compare so many things at once, and it can only conceive of a certain range of things. If I had a dozen items on my backlog that were all small, like changing UI elements or moving buttons around, and then I had something huge, like creating a learning algorithm to master the stock market, my team won't be able to adequately compare them. They will have become "anchored" on the small items, so when the huge item comes up it will either be estimated way too small or way too big. What happens early in an exercise sets people up for what happens later.

  This has huge implications for backlogs in general, but for now, just remember to try to keep the range of relative sizes small. Some folks use High, Medium, and Low (H/M/L). Some folks use geometric numbers, like 1, 10 ,100, 1000. Some folks use the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, ...) There's nothing magical about any of these, save for the fact that there is a small number of discrete choices (you have to pick one of the options), and the choices are separated by a significant (or growing) amount.

  I I want to make my life more complicated than it needs to be -- and isn't that fun! -- I'll use a two-level H/M/L system set on top of a Fibonacci sequence. So first the team splits up the items into High, Medium, and Low. Then we take a second pass for all of the highs and split them into High-Low, High-Medium, and High-High. Same goes for the Mediums and Lows. This gives me a range of nine positions, which would normally be way too much, but because I am asking for two sorts of three ranges each, it still works without undue anchoring. As a final step we go through and cross-check to make sure the sort makes sense to everybody. Remember whatever you do, as you get good at this it shouldn't take more than an hour or so, hopefully much less. If you're taking more time than that, your project has significant risks that need to be addressed before you go on. (By the way, that's completely normal, especially in first-time projects. Team members will have lots of questions and want to address lots of risk. Be prepared to spend some time on this during your first estimation. Estimation drives out conversation, which creates team understanding and resolves conflict and risk. It's not just about picking numbers out of a hat. Remember that everything we do is to drive out conversation and understanding.)

• Estimate Each Item Individually - Lots of PMs want to create a dependency chart before estimating, with Task C dependent on Task B which is dependent on Task A and F. Don't do this. It feels good, I know, but it's just creating cognitive noise where none needs to exist. Instead, estimate each task as if it's the only task you're completing. Later on we'll worry about dependencies and scheduling. Lots of little, simple things done repeatedly. Of course, if you have some monster task that has to be done first, like creating your development environment or setting up the network topology, that's going to be a huge item for every story. So just take it out, and later on you can add it back in as one of the initial things you have to do. If you'd like to break it out now and size it fine, but since these huge things have to be done no matter what, the relevant question is whether you can do them in one timebox or not, NOT how big they are. (think about it)
• Estimate Before You Prioritize - Do not schedule or prioritize your work before you estimate. Studies have shown that people will think of something many months from now as being smaller than something next week. If you start telling people that certain items won't be done for six months, they're going to estimate the size smaller. So put it all on the table, and make sure that everybody is estimating the relative complexity as if we were starting on this item tomorrow. The only way to do that is not to show any sequence information before sizing. You can tell people to forget about what they saw, but it doesn't work that well.
• Diversity is Good - Some texts will tell you that everybody on the team has to agree on the number for a certain task/story. That's nonsense. Diversity is a good thing. What I always do is tell folks that "the worst guess wins" -- the most pessimistic guesser is the one we're using. Of course, if you have somebody who's pulling the entire thing out of whack the team needs to talk to him, but "talking to each other" is the whole idea anyway, so there's no downside. Be careful with games and such that force quick unity. Unity is a great thing, but much more interesting is diversity and the reasons for it. Look at it this way: I can create a dozen games that let the team pick a number for a story, but it's impossible for me to create a game for a team to talk about the risks on a project and what's keeping them from delivering. Picking the number is the easy part: having the conversation is the tough part. Games (exercises) exist to create the conversation -- all the other stuff is window dressing. No matter how quickly you size up your stories, if you're not talking about critical project issues you're going to fail. Don't confuse the mechanics of something with the real purpose of it.
• Attitude Beats Skill - Speaking of soapboxes, attitude plays a huge role in sizing. Remember that you're going to be sizing a lot in this project, so don't get out of sorts. After the first sizing effort, which can and should get chaotic, if you're taking too long to size each sprint start timeboxing your sizing efforts. The team is trying to learn, as a group, how to estimate how long things will take in this particular project. Nobody walks into the room knowing this, and the dynamics of the project keep changing from sprint to sprint. So it's a learning process, it's supposed to be chaotic, and it gets better over time. Lots of PMs freak out when their first sizing meeting runs over an hour. An hour! Wow!
• Estimate From the Outside In - Finally, another tip from psychology: studies have shown that people estimate projects better if you ask them how long it would take some other team to do the work instead of their team.. That means the final, critical step is to take all of the information you've gathered in estimating and then "step outside the team" to pick your sizes.

Good teams talk a lot about what's going on in their project. They know that communication is the number one problem all teams face. We have a lot of stuff we need to do in a project, like tell folks when things are going to be completed, get feedback from users, or agree on design principles. As we go about doing these things, we use exercises to help us along. But we make a mistake if we confuse the exercise with the larger purpose of the project. You can be in a sizing discussion and segue off into a design talk -- that's perfectly fine if it's required for sizing. If the team is talking about big things first, and getting resolution on these big issues, then the "craziness" of having teams spin off like this will dissipate over time. If you're not doing these things, then it's time to start.

Hope this helps. Next time we'll talk about release planning -- how to take these relative numbers and make them into something that you can show the guy who writes the checks.