We all know the challenge of estimation. For agile teams this is especially true as it’s all about small teams building high quality software according to aggressive milestones. Accurate estimating is a critical building block to achieving agile objectives (in fact, LiquidPlanner counts many agile teams as customers).

Planning poker was popularized by Mike Cohn in 2002 as a consensus-driven estimation technique. The “game” is based on a list of features (or “stories”) to be delivered and a deck of cards that represent units of time. A moderator is chosen to administer the session, features are described in terms of scope, and then team members simultaneously turn a card over that represents how long they think a given task will take. If everyone is on the same page, take one step forward! Mark the estimate in the schedule and move on to the next task. If estimates diverge, then the developers are encouraged to discuss their different estimates in an effort to gain consensus. They then choose a new set of estimates, select new cards that represent a revised estimate, and then reveal them once again to the group. Wash, lather, repeat.

This is essentially an analog version of what LiquidPlanner provides with ranged estimates (one that unfortunately requires the entire development team to take valuable time away from actually developing software). Ranged estimates obviate the need to drive consensus at a macro level because each task owner is liberated from having to come up with (i.e., guess) and stake themselves to a single number. Rather, if there is a great deal of uncertainty around a specific task, they simply reflect that in their range. Since all of the other team members can see one another’s estimates within the application itself, there is room for a dialogue as to what is and what is not realistic in terms of estimates. As work is completed on a given task, a developer can simply reduce the range to express that there is less uncertainty and the entire plan is then rescheduled accordingly.

Planning poker is actually a great idea for a bygone era — it succeeds in bringing all project constituents to the table (literally) to achieve consensus. It can work well for making estimates at the inception of a project but as we all know, those best guesses are just that — guesses. Most of the time, we don’t really have a good idea for how long something will take until we actually begin the work. Specifications change, obstacles arise, sh*t happens. Of course, because so many companies these days rely on offshore developers to build their products, it’s even more difficult to bring all parties to the table. In any event, unless you intend to play planning poker every day, this methodology is not truly sustainable. At least not in a true agile environment.

————————————–

Robert Nachbar is the Principle of Kismet Communications, a Seattle-based public relations consultancy that works with technology start-ups. As the result of his work with LiquidPlanner, Rob has developed a surprising interest in all things project management, so much so that he is occasionally compelled to blog on the topic.

I’ve heard from time to time people saying that LiquidPlanner “automatically buffers” their tasks.  It is easy to see how you could think this.  After all, when you put a bunch of uncertain tasks into LiquidPlanner the schedule comes out looking longer than it would using a more primitive scheduling system.  however the added time represents real increases to the likely schedule, not added buffer.

To see this let’s take a look at a sample schedule with two people, each of them working on a 2-4 day task.

You can see that Project Baby Bear’s end dates extend past the end dates for the individual tasks.  So, isn’t this project buffer?  Well, not exactly.  While it could be considered buffer for the uncertainty in the individual tasks, it is not what most project managers would consider risk buffer.  That is, it does not account for all the things in Project Baby Bear that could possible change or go wrong.  It merely takes into account the two tasks (Anne’s Task and Bruce’s Task) and the uncertainty expressed in them.

Suppose one of the risks in the project is that either Anne or Bruce gets sick (a not unreasonable project risk).  The uncertainty in the size of the tasks does not take this risk into account.  Instead, an additional risk buffer should be put in place to account for this risk.

Let’s suppose that we think that the longest that either Bruce or Anne might be out sick would be one week.  LiquidPlanner is predicting a 90% confident end date on Thursday 1/15.  So I would place the promise date for Project Baby Bear after 1/22.  Let’s make it Friday 1/23.

I double click the project to edit it and set the promise date to 1/23 on the scheduling tab.  Now when I click save and the schedule updates (remember that you can continue to work while the schedule is being updated) I see that the promise date icon appears a week after the predicted end of Project Baby Bear.

Alternatively, I could build into the schedule a specific task called something descriptive like “risk buffer” and use dependencies to make it follow all of the tasks in the project.  But that would be hard to maintain and really kind of overkill.

The last 20% of the work takes 80% of the schedule. How many times have you heard of this happening?

The project is cruising along. Work is getting done. The percent complete steadily rises until it hits about 80-90% and then it stalls. It just sits there at 90%. Days go by. The team is working, but every time they’re asked for an update the answer comes back the same, “We’re almost done, just another couple of days.”

Ignoring the problem of chronic underestimation, why does this happen?

One reason is using percent complete to record progress. Let’s take a closer look at percent complete.

Suppose we have a project that has 10 team members with 10 days of work each. This gives us a total project size of 100 days of effort (making our calculations super simple).

On day 9 of the project the project manager reports that the team is 85% complete. How late is the project going to be?

Well, it is tempting to say that the team has been knocking off just over 9% of the project work per day so tomorrow (the scheduled end of the project) they should be 94% complete and then the project should end just one day late.

Sure enough, the next day the team is 94% complete. Great! But the next day it is 95% and the day after it is 96% and…

The project comes in 5 days late. Fully 50% behind schedule. What happened?

What happened was that Larry (known as “Late Larry” to the rest of the team) started on his 10 day task 5 days late. So by day 10 Larry still had 5 days left to work. Tracking percent complete made this impossible to see from the project level.

So, what to do?

I think the best way to avoid this kind of thing is to always ask, “How much work is left?” And ask for it in a range. By asking how much is left instead of how much got done you allow for the fact that people learn more about the task as work on it progresses. It is extremely unlikely that the original estimate is right on target and asking how much is left is a good, non-confrontational way to get this important schedule information. Asking for a range reinforces the idea that we expect that estimates change as the work gets done.

Be bold! Toss out percent complete and focus your project team on looking forward to what is coming up by monitoring the work in front of you rather than focusing on the past.

I admit it, I love my iPhone. It really has transformed my life, at least in the sense that there is always something to fill any unallocated moment.

I pet my iPhone in the Starbucks line and it purrs back with a flyby of my inbox. I unlock and re-lock at stop signs just to hear it click. And then there are the apps; I have a little 99 cent habit. I can’t help it because I love well designed toys as much as well designed tools.

I’ve found an application that is worthy of a little praise for its incredible simplicity and yet amazing ability to deliver fun; it’s called SpinArt.

If you have kids, like random art, or want to make market predictions, then this is a must have. Just flick the tile to start it spinning and poke it to start the paint flowing. My favorite trick is to saturate it with color and then start using white for a little crisp style.

Here’s my “best of” gallery show; should I quit my day job?

I watched Malcolm Gladwell’s talk at the 2008 New Yorker Conference. It is a good talk and you should watch it. He’s talking about something he calls “the mismatch problem”.  While quite interesting, I really have nothing to say about it. Rather, I’d like to riff for a few minutes on a couple of things that he said in the talk taken completely out of context. I get to do this because… well… I’m the author.

“[It] has to do with our desire for certainty… we have a desire to impose certainty on something that is inherently uncertain.”

“We have this sense that progress, broadly speaking, has the effect of reducing uncertainty. But the opposite is true.”

- Malcolm Gladwell

What struck me about these quotes was that he’s expressing something that I see all the time in project management. That the desire for a plan that shows with certainty that things will go according to a specific schedule overrides the desire for really truthful information about the project. This desire for certainty, even a false certainty, often causes project teams to delude themselves about the realities of their projects.

In many ways, you have to admit to yourself that things are uncertain. You must embrace the uncertainty, before you can begin to control a project. The harder you try to resist and force a false certainty upon the project and the project plan, the more out of control the project becomes.

The very act of trying to tightly control a project can in the end lead to its failure.

So open your arms. Embrace the uncertainty!

So, I stumbled across this quote by Sir Francis Bacon (you know, the guy who invented the scientific method) regarding the relationship between doubt and certainty.

If a man will begin with certainties, he shall end in doubts;
but if he will be content to begin with doubts he shall end in certainties.
- Sir Francis Bacon

It got me thinking because I this happens all the time in projects. And you know what happens when I start thinking… blog post. Yeah.

Oh yeah.