*
programming and human factors
by Jeff Atwood
*
One of the most challenging aspects of any software project is estimation-- determining how long the work will take. It's so difficult, some call it a black art. That's why I highly recommend McConnell's book, Software Estimation: Demystifying the Black Art; it's the definitive work on the topic. Anyone running a software project should own a copy. If you think you don't need this book, take the estimation challenge: how good an estimator are you?
How'd you do? If you're like the rest of us, you suck. At estimating, I mean.
Given the uncertainty and variability around planning, it's completely appropriate that there's a game making the rounds in agile development circles called Planning Poker.
There are even cards for it, which makes it feel a lot more poker-ish in practice. And like poker, the stakes in software development are real money-- although we're usually playing with someone else's money. If you have a distributed team, card games may seem like a cruel joke. But there's a nifty web-based implementation of Planning Poker, too.
Planning Poker is a form of the estimation technique known as Wideband Delphi. Wideband Delphi was created by the RAND corporation in 1968. I assume by Delphi they're referring to the oracle at Delphi. If anything says "we have no clue how long this will take", it's naming your estimation process after ancient, gas-huffing priestesses who offered advice in the form of cryptic riddles. It doesn't exactly inspire confidence, but that's probably a good expectation to set, given the risks of estimation.
Planning Poker isn't quite as high concept as Wideband Delphi, but the process is functionally identical:
There's nothing magical here; it's the power of group dialog and multiple estimate averaging, delivered in an approachable, fun format.
Planning Poker is a good option, particularly if your current estimation process resembles throwing darts at a printout of a Microsoft Project Gantt chart. But the best estimates you can possibly produce are those based on historical data. Steve McConnell has a whole chapter on this, and here's his point:
If you haven't previously been exposed to the power of historical data, you can be excused for not currently having any data to use for your estimates. But now that you know how valuable historical data is, you don't have any excuse not to collect it. Be sure that when you reread this chapter next year, you're not still saying "I wish I had some historical data!"
In other words, if you don't have historical data to base your estimates on, begin collecting it as soon as possible. There are tools out there that can help you do this. Consider the latest version of Fogbugz; its marquee feature is evidence-based scheduling. Armed with the right historical evidence, you can..
Predict when your software will ship. Here you can see we have a 74% chance of shipping by December 17th.
Determine which developers are on the critical path. Some developers are better at estimating than others; you can shift critical tasks to developers with a proven track record of meeting their estimates.
See how accurate an estimator you really are. How close are your estimates landing to the actual time the task took?
See your predicted ship dates change over time. We're seeing the 5%, 50%, and 95% estimates on the same graph here. Notice how they converge as development gets further along; this is evidence that the project will eventually complete, and you won't be stuck in some kind of Duke Nukem Forever limbo.
Witness, my friends, the power of historical data on a software project.
The dirty little secret of evidence based scheduling is that collecting this kind of historical data isn't trivial. Garbage in, garbage out. It takes discipline and concerted effort to enter the effort times-- even greatly simplified versions-- and to keep them up to date as you're working on tasks. Fogbugz does its darndest to make this simple, but your team has to buy into the time tracking philosophy for it to work.
You don't have to use Fogbugz. But however you do it, I urge you to begin capturing historical estimation data, if you're not already. It's a tremendous credit to Joel Spolsky that he made this crucial feature the centerpiece of the new Fogbugz. I'm not aware of any other software lifecycle tools that go to such great lengths to help you produce good estimates.
Planning Poker is a reasonable starting point. But the fact that two industry icons, Joel Spolsky and Steve McConnell, are both hammering home the same point isn't a coincidence. Historical estimate data is fundamental to the science of software engineering. Over time, try to reduce your reliance on outright gambling, and begin basing your estimates on real data. Without some kind of institutional estimation memory-- without appreciating the power of historical data-- you're likely to keep repeating the same estimation errors over and over.
What do you *MEAN*? 10 years is a perfectly valid amount of time to spend developing a Duke Nukem game.
Curtis on October 22, 2007 4:15 AMI bought McConnell's book because I am lousy at estimating. I also bought it because I enjoyed "Code Complete" and "Rapid Development".
So I took the estimation challenge thinking that I would ace it.
I scored 5! I couldn't believe it.
I think most developers are bad estimators - we need all the help we can get. I think it was Fred Brooks in the Mythical Man Month who said that developers are optimists and assume that everything will go smoothly. It never does.
Our internal system already supports this "poker" system internally: blind estimates by feature with estimates averaged out (or occasionally thrown out). We actually take this one step further though and evaluate the relative importance of features in the same way.
So not only do we know what takes the longest, we also know the most important features. This means that we can load balance individual features and provide the client with working builds earlier. This of course manages both estimation errors and specification errors as early as possible. This is something Fogbugz doesn't seem to do (we just played with the 6.0 release, and I could be wrong)
Gates VP on October 22, 2007 4:50 AMThe first part reminds me of the 'average of 3 independent estimates' technique used to estimate the range for artillery or mortar. Apparently this works well in practice.
Another good technique for estimation attempts to weight each task estimate by the amount of uncertainty of that task. So the time estimate would be weighted by 1 for a module that can be coded without thinking. If the task is using an unfamiliar technology, then the time estimate would be weighted much higher. I find the exact numbers are unimportant but the introduction of uncertainty definitely helps!
Tom on October 22, 2007 4:52 AMHey Now Jeff,
Your right on it's so tough to determine an estimate time a project will take. Very interesting post.
Coding Horror Fan,
Catto
Sorry for the service interruption-- I switched servers and changed DNS, and I forgot a few things along the way.
Jeff Atwood on October 22, 2007 8:36 AMI also own McConnel\s lates book, although I haven\t finished - my collegues look at me funny when I pull it out. Estimation is the most annoying thing, mostly because it can\t be done. For some reason, I always estimate optimistically and that comes back to bit me in the butt when a manager doesn\t understand why it isn\t done.
In the very first PC book I got, there was a trick about buying HD space. When all is taken into consideration, double it and then round up to nearest GB. I almost think it would serve me well with estimation too.
Casper Bang on October 22, 2007 9:18 AMI always think of the story from ancient China. They wanted to make a statue of the Emperor, and all was arranged for the sculptor except for the length of the Emperor's nose. Being divine, they could not just go up and measure it, so they decided to take a poll. They asked every member of the country how long they thought is was and took the average.
That had to be close - Right?
The moral is "a whole bunch of people guessing is still a guess".
Paul on October 23, 2007 2:02 AMIt is interesting to me that this notion of using historical data to predict future estimates is finally making its way into the software world.
We have been using historical data in the oil and gas industry (any continuous process industry actually) to predict when equipment will break, how much it will cost, and what can be done to prevent it. There is actually a software niche centered around this. Reliability Centered Maintenance was started by the airline industry and is slowly making its way to different segments. Looks like the agile development folks are picking up on it as well ;-)
Stephan on October 23, 2007 2:19 AMIgnoring task dependencies is ridiculous. I mean, there is a reason they are called 'dependencies'... doh!
Tubs: Try just multiplying by four, and save half your estimate-doubling time!
Jeff said:ISome developers are better at estimating than others; you can shift critical tasks to developers with a proven track record of meeting their estimates./i
Ah, but might this be true because of the sorts of tasks the first set of developers are doing?
Unless there's a round-robin of tasks to developers, there's a risk of conflating cause and effect in estimate accuracy.
(Your shop's mileage and practises may, of course, vary.)
Sigivald on October 23, 2007 3:34 AM"a whole bunch of people guessing is still a guess"
True. Estimation is always going to involve a certain amount of guess work, otherwise it wouldn't be an estimation.
Aside from the actual accuracy of the estimate, another advantage of the group approach is that everyone takes responsibility for the "guess".
If/when it all goes wrong then the group can ask itself "why did WE get that estimate so wrong?", rather than the more confrontational question of "why did YOU get that wrong?".
Graham Stewart on October 23, 2007 4:04 AMAs a rule of thumb, I make an estimate. Double it. Then double it again.
Even somthing as simple as rebooting a server always takes longer than you think.
Tubs on October 23, 2007 4:05 AMSorry for the service interruption-- I switched servers and changed DNS, and I forgot a few things along the way.
How long did you estimate it would take? ;)
I'm very sorry I don't think I properly understood the task.
You could just estimate a range your guaranteed to get the answer withink but what's the point. For the first question we could just say 100 as a minimum knowing that the sun is hotter than boiling water and we could say 1,000,000,000 as a max just because we are sure then we would be within the range but that's not an estimate that's just a joke.
You can't plan anything based on that estimate so it's pointless.
You want someone to say between 10,000 and 12,000 for instance because you can use this answer.
I realise it could be wrong. I think i am missing the point here.
Surely an estimate is a narrow range and a good estimate is a narrow range that is also pretty accurate. That comes with experience.
Enlighten me on the opint i'm missing, if any :). Thanks
Robert on October 23, 2007 4:52 AMWe've just started using Rally: http://www.rallydev.com/.
It's phenomenal. Designed specifically for Agile planning and development, models stories, iterations, releases ... the works.
We've hooked it up with Jira for our defect tracking.
Whenever I hear a estimate, I always double it, and add half. It's amazingly close to what the actual time is, esp. when it comes to networking issues.
Rocketboy on October 23, 2007 5:32 AM"2. Each estimator gets a deck of cards: 0, 1, 2, 3, 5, 8, 13, 20, 40, and 100."
OK. In order to have 90% confidence that the result will be in range, each estimator plays both their 1 and 100 cards.
"5. If the estimates vary widely, the owners of the high and low estimates discuss the reasons why their estimates are so different. All estimators should participate in the discussion."
OK. 'I played my 1 and 100 cards in order to have 90% confidence. Why did you play your 100 and 1 cards?'
McEstimator on October 23, 2007 7:11 AMDuke Nukem Forever is titled as such, because it will take FOREVER to be released.
Billkamm on October 23, 2007 7:34 AMFrom what I've read about planing poker, having around 7 players is around the sweet spot.
I'm on a team of only 3 people. We tried a set of planning poker, and my teammates pretty much just went with what I picked (I'm the "lead"). One guy is fairly new, so he wasnt able to contribute much. That leaves only 2 people discussing the numbers. If the "moderator" didnt participate, that'd leave 1.
Any thoughts on what we could do to improve our estimates? I thought of just pulling in people from other teams, but they'd just be pulling numbers out of their whatsit.
Gary on October 23, 2007 7:35 AMWe use a formula
Actual Time + Worst Case Scenario Time / 4 + Actual Time
It actually comes really close
Zerolove on October 23, 2007 7:37 AM"You want someone to say between 10,000 and 12,000 for instance because you can use this answer.
I realise it could be wrong. I think i am missing the point here.
Surely an estimate is a narrow range and a good estimate is a narrow range that is also pretty accurate. That comes with experience."
You are missing the point. An estimate that does not contain the correct answer is useless. We've been trained to see a narrow range as "good" and broad as "bad". A narrow range isn't accurate, it's precise. And precision is useless if you are precise about the wrong thing.
Let's use your sun example. Using the first estimate of 100C - 1,000,000,000C to build a ship to travel to the sun will yield a ship that can withstand the heat. Because we've built it to withstand temperatures from 100C to 1 billionC.
Using the second example, if the temperature of the sun is 20,000C, your pilots fry because your ship won't be built to withstand the temperature because you worked under the assumption that the sun will never go above 12,000C.
Same thing for estimating project time. If you are unsure, use a really broad range (1day - 1week) to convey that uncertainty. That way when you come in at 3.5 days, no one is surprised and you are now ahead of schedule.
This is not a signal to reduce the estimate however. If you reduce all of your estimates by half due to this one data point, you are now going to be extremely late. Because those items that were going to run over their estimated times are now going to really run over.
Rule of thumb is to cover 80% of your certainty with your estimate. You should have about a 10% chance of making your low estimate and a 90% chance of making the high one.
Your end schedule should have about a 90% chance as well. And estimate as finely as you can. If a task can be broken up into two discrete sections, estimate each individually.
The finer the pieces, the better the estimate. The more data you collect, the better you will be at estimating.
It's all in the book.
BA on October 23, 2007 7:49 AM"Delphi" is almost certainly a reference to the Delphi Method, not the Delphic Oracle. Using the Delphi method, a number of individuals gives separate and independent opinions, get feedback on the views of others, give opinions again, and eventually converge, without ever having any face-to-face confrontations. It's a good heuristic for reaching agreement using impersonal debate, and avoids problems like groupthink.
The Delphi method supposedly dates back to about 200BC when some king wanted biblical writings translated into Greek. The king got a bunch of scholars, locked them in separate rooms, and had them prepare translations. When they were finished, they were all identical. The king was amazed, but a rabbi who looked at the translations said that getting n identical independent translations wasn't a miracle, getting n scholars in the same room to agree on a single translation would be have been a miracle. This is probably just a good joke rather than the real origin of the method, but it's a nice example of how it works.
Peter Gutmann on October 23, 2007 9:13 AM"Agile Estimating and Planning" by Mike Cohn also does a good job discussing Planning Poker. Cohn also sells card decks on his web site.
It's important to make the distinction between estimating stories based on relative size and estimating the hours a task will take. Size is "fixed" -- a pile of dirt is the same size no matter who is shoveling it, but one person will take longer to shovel the pile of dirt than someone else.
Jeremy Weiskotten on October 23, 2007 9:55 AMI am surprised no-one mentioned use case estimation models?
In most pro services shops, that I have worked for anyway where fixed price estimates are the rule, software requirements are typically documented via use cases, which feed into one of these use case estimation models that can be tuned for complexity, technical factors, team experience, history, etc. Once “calibrated”, it turns out to be reasonably accurate. Reasonably being the key word.
Most importantly, it becomes a predictable and repeatable process. And the last time I played poker, the only thing predictable or repeatable about it was losing my you know what ;-)
You want to see the level of detail in collecting time and size measures? Download Watts Humphrey’s Personal Software Process (PSP): http://www.sei.cmu.edu/pub/documents/00.reports/pdf/00tr022.pdf
Mitch on October 23, 2007 10:13 AMInteresting timing... I was looking at the Evidence Based Scheduling feature of FogBugz just yesterday -- read some of the forum entries, and watched the video, too.
The thing that I didn't see addressed was task dependencies. What if some of Jane's tasks depend on one of Milton's being complete? This clearly means that Jane's completion date isn't solely based on the accuracy of her estimates, or even the estimates after adjusting for historical data. She simply can't start until Milton is finished.
While this may not be the right forum in which to ask, but does anyone know if the FogBugz EBS feature addresses task dependencies?
JK on October 23, 2007 10:52 AMTighter estimates are better, right?
http://blogs.msdn.com/philipsu/archive/2006/06/14/631438.aspx
As part of the agile process there is the concept of 'velocity'. This is based on historical data and basically uses the results of the planning poker to determine how bad we are at estimating.
So after a few iterations we can see that when the group predicts that something is going to take 5 days, then actually it will take 8, or some such.
This is a nice, simple approach to getting historically informed estimates. The thing it doesn't deal with that well are blow outs (where are single piece of work takes considerably longer than expected) or dependencies (but from a statistical point of view I don't think that should really be all that important.
Tiest Vilee on October 23, 2007 11:46 AMFogBugz estimating doesn't support dependencies. They have a story about why dependencies don't matter for software development estimating.
If you want to build a space satellite, you need to worry about dependencies, create Gantt charts, and find the critical path. But for software development, you can probably assume that no one on the team will stand idly by waiting for the dependencies of "their" part to be satisfied. Just break the entire project into parts no longer than two days each and add up the number of days. At least that's the argument. Probably a good argument for a seasoned team working on the next release of a product.
Howard on October 23, 2007 11:57 AMI enjoy planning poker and have seen a lot of benefit from it when the entire team really participates. We all suck at estimating, and we all have some historical data from past tasks that have been completed. Where we get into trouble is that just like the stock market, past performance does not necessarily reflect future results.
A future task often involves new approaches to an old problem and may take much longer than previous approaches until the developer becomes more comfortable with a new technology. Indeed, discussions often turn to asking why a particular task exists if we find that it is easy to estimate based on historical data. The team often wonders if such a task is necessary at all.
Another influence on poor estimation I notice is the human aspect. Some historical data may have been generated during a time when the developers were particularly "on fire" and they may not be as energetic, motivated, or diligent in the future, or vice versa. Even the frame of mind at the time of estimation may come into play and how someone feels can dramatically influence the estimation. The developer may be in a very different mental state when the task is actually performed. Planning poker helps mitigate these all-too-human influences.
Finally, I see team members lose interest in estimating at all when features are added to a project as quickly as they are completed. We see velocity and project completion dates actually diverge and the attitude quickly becomes one of just get it done. When I see this happen I find more and more of my time is devoted to ensuring that historical data is still collected as accurately as possible especially as it predicts future ship dates moving to coincide with Duke Nukem Forever."
gdc on October 23, 2007 12:07 PM"Collective Intelligence" is a key benefit of Planning Poker. In "The Wisdom of Crowds: Why the Many Are Smarter Than the Few and How Collective Wisdom Shapes Business, Economies, Societies and Nations, "
James Surowiecki does a great job of discussing the many ways that we are collectively better at some tasks than we are individually. For example, there is the phenomenon that when guessing how many small objects like marbles are in a jar, the average of all the guesses is often more accurate than any individual guess. How often has estimation felt much like guessing how many marbles are in the jar?
I'm just going to chime in with Mitch's earlier reference to the PSP text. While no where near as delightful to read as Steve McConnell's work, it does delve deep into the math. I worked on a team that used it for 4 years, and it didn't take long for the results to improve.
Our management used MS Project to handle task dependencies, and as Howard pointed out--there's always *something* to do, so keeping everyone busy was rarely a problem. In fact, it turned into growth opportunities for some, because there was time available for them to take on a task more challenging than some they were originally scheduled.
This stuff works. Most people balk at collecting the data. Tools help, but as Jeff said, it still takes discipline. But, you might be surprised how many fewer times your boss interrupts you when your data shows those interruptions (or the tasks associated with them) are what caused your task to be late! (Or, sadly, if you live in Dilbert's world, the boss might say to stop tracking your time like that, because it only shows you can't get done the things he wants you to do.)
Daniel 'Dang' Griffith on October 23, 2007 12:47 PMA friend once told me that to estimate the time of any software project, take your best guess, double it and move it to the next time unit up.
So, two hours become four days and a day become two weeks, get it?
"OK. In order to have 90% confidence that the result will be in range, each estimator plays both their 1 and 100 cards."
Read step 4. You only "play" a single card, which you think best represents the size of the problem.
Also note that relative sizing is typically used: playing a 2 doesn't mean two days. It just means you think this task is bigger than the 1 tasks, but smaller than the 3.
Graham Stewart on October 24, 2007 3:16 AMIf each estimator plays a single card, then no estimator has a 90% chance of being right (on average). Even if just trying to compare the expenses of two tasks instead of trying to estimate the orders of magnitude of difference between them, still no estimator is going to get 90% of them right (on average).
OK, throw out yesterday's book on estimating and buy today's book. Tomorrow, we'll throw out today's book and buy tomorrow's book. As much respect as I used to have for McConnell's ideas, I'm sure glad I didn't waste money on that book.
McEstimator on October 24, 2007 7:11 AMWe tried this just the other day in our five developer shop.
My first impression was that it was kind of hokey, but as we went along I came to like the process. There really is a 'wisdom of crowds' effect. And its fun.
Jim Howard on October 24, 2007 9:32 AMIf you're curious about how FogBugz handles estimation, you can watch the Austin leg of Joel's tour here:
http://www.joelonsoftware.com/items/2007/10/24austindemo.html
I attended the Emeryville, CA presentation. It was great to meet Joel in person, and I was very impressed with FogBugz-- particularly the estimation and timesheet stuff.
Jeff Atwood on October 24, 2007 11:39 AMJoel goes into more detail on evidence-based scheduling:
http://www.joelonsoftware.com/items/2007/10/26.html
Jeff Atwood on October 26, 2007 12:24 PMThis technique is common in the Agile world, and is usually used with story points as the unit, rather than any unit of time. The rationale is that developers are better at comparing complexity of tasks than estimating the time they will take to complete them.
Once you have a couple of iterations under your belt, you can start looking at the velocity (story points/iteration, say) and have a look at where you'll end up. You can also use the best and worst 4 (or so) iterations to get a range of delivery dates, if you wish. It's also then relatively easy to predict the effects of feature creep, and the like.
However, I'm not so convinced of the value of historical data. Story points measure the **relative** complexity of a set of tasks. So unless you're always comparing to some sort of standard, I would have thought a history of estimates, progress etc on other projects would be of limited use.
As indicators that can be used to improve your process? Possibly. To show the effect of good and bad decisions? Sure. But as a basis for estimating other projects? Hmmmm, dunno. Jon make some good points about this.
However, I **am** completely convinced of the utter uselessness of Gantt charts for anything more detailed than product roadmaps. They just cannot model software development processes accurately, especially anything remotely Agile.
Worse, they generate useless, yet comforting, information, especially with regard to critical paths. In a well designed piece of software, there just aren't many actual dependencies. If there are, it isn't well designed. So usually, any "critical path" a Gantt chart shows is mostly an artifact of the order you decided tasks should be done.
For software projects, bin MS Project, it's completely counter-productive.
Jim Cooper on November 1, 2007 12:14 PMNice blog! More people should read it. If you want, you can register your blog Pokerweblogs.com .It is free and and it automatically updates when you do an update, so visitors of our site can see when you updated your blog. The big advantage is that it will attract much more visitors to your blog.
Greets Peter
Peter on December 22, 2007 7:03 AMThe first part reminds me of the 'average of 3 independent estimates' technique used to estimate the range for artillery or mortar. Apparently this works well in practice.
Another good technique for estimation attempts to weight each task estimate by the amount of uncertainty of that task. So the time estimate would be weighted by 1 for a module that can be coded without thinking. If the task is using an unfamiliar technology, then the time estimate would be weighted much higher. I find the exact numbers are unimportant but the introduction of uncertainty definitely helps!
Poker on February 4, 2008 11:59 AMI think an important distinction is that between estimate and guess. Guess is just arbitrary while an estimate - if the person worth any cent as an engineer - is based on past experience with similar tasks. In practice the estimates achieved with planning poker become better with each release cycle if the team members are sufficiently experienced in working with each other. So an estimate is not necessarily a guess but it could be. As a project manager it is your duty to talk to your people and find out.
Planning Poker definitely supports collaboration and team learning. The discussions around specific tasks help all people in the team to challenge their assumptions. In the end the estimate becomes better - but it is still not a prediction - and the buy-in from the team is improved as well.
A printing template for creating the card game yourself is available for free at http://www.agileutilities.com/products/AgileAuction
Kind regards,
Manfred.
@Curtis (first comment): Make that 11 (will be 12 in a few months), I think it now qualifies for a case study on how Project Management went wrong...
PM Hut on October 26, 2008 6:18 AMI have to agree with Manfred - the benefits from planning poker also come from the discussion and shared decision - it is not just a numbers game. Sometimes getting everyone to input to the conversation is the most important thing.
btw you can get really good quality cards from www.agilehardware.com - you can use them again and again
laila on March 4, 2009 5:27 AMHi all,
you can buy nice Planning Poker Cards at the homepage of agile42.
http://www.agile42.com/cms/pages/poker/
Have fun
Marion
Nice post. One additional advantage of planning poker that I recently blogged about, http://onemoreagileblog.blogspot.com/2009/03/using-planning-poker-to-ensure-common.html, is that it helps create a common understanding of a story at a team level.
In short, if all team members throw around an 8 and one throws a 40, then the one guy has an incorrect assumption of the work or what the scope of the story is, or that person knows something the rest of the team does not. Either way, it's a a great starting point for discussion.
Similarly, if the numbers are all in the same ballpark, move on. In these estimation/planning sessions, the goal usually a high level estimate to help plan, it is not a design or tasking session.
RichC on March 19, 2009 3:01 AMI'm useless at estimating and I know it's for 4 reasons.
i) I don't track historical data.
ii) I'm over-optimistic even when I think I'm being pessimistic.
iii) I don't start by really, properly designing.
iv) I'm not assertive enough to make sure I get the resources I need quickly to make sure I get the debugging done quickly.
Planning poker sounds almost like socialized groupthink, Jeff. A clever way to CYA through dialogue and consensus, almost like a manager-based dissertation on estimation. The comparison to the Oracle of Delphi is merited.
However, the tool by Mr. Spolsky sounds very promising. The only trouble is getting others to focus and donate time to the next project while they are focusing on this one. It is hard to ask for more seemingly unimportant documentation when the sun becomes a quaint visitor that comes up and goes down while you are at work.
Ryan Moon on February 6, 2010 10:14 PMI must say I disagree. Are you doing Agile development Jeff? Have you used PlanningPoker on a live project?
I do agree with the importance of historical data, but not in the way it’s described here. Focusing on a single person, how good he is to estimate and how reliable he is of doing his work? Do you want that? I certainly don’t! I prefer looking at the team and not the individual. When we do Agile development our historical data is our velocity. How much work (or how many story points) can our team do in one sprint.
When it comes to estimates I don’t really care if the estimate on one single item is accurate or not. What I care about is that our team actually manage to complete the amount of story points we committed to for one sprint or iteration.
“Without appreciating the power of historical data-- you're likely to keep repeating the same estimation errors over and over.”
I say: “Please keep repeating the same estimation errors, because that will let us continue the deliver on time!”
Why is that? Well, that’s where the Agile approach has its advantage. Over time the estimation error will be washed away by the velocity. As long as you stick to your estimating mistakes, the team will only commit to what it actually is able to achieve, and that will be more and more accurate over time. Why? Because we learn by our mistakes. The first sprint my team committed to, we learned that we committed to too much, so we committed to a bit less the next time. Later we committed to less than we were able to do, so next time we committed to more. At this time we all have a feeling of how much we’re able to commit to and we’ve become very good at it. We’re still not hitting the estimates on an individual story or feature, but who cares as long as we deliver at the end of the sprint!
“There's nothing magical here; it's the power of group dialog and multiple estimate averaging, delivered in an approachable, fun format.”
Average isn’t really the point. Letting people with different opinions, conceptions and knowledge of the story to estimate is. Someone might (and probably do) know something that you don’t, and planning poker is a way of surfacing this knowledge.
Planning poker sounds hilarious! At the moment, the company I work for (a design/development/marketing agency) use a program called Gemini (http://www.geminiplatform.com). I'm not sure if you have heard of it?
It's quite useful but unfortunately I don't get to use it to create estimates as I'm not a developer but I will also show the development team this (maybe they'll stop playing Age of Empires 2???) and see what they think!
Seocolin on May 20, 2011 8:42 AMThe comments to this entry are closed.
| Content (c) 2012 Jeff Atwood. Logo image used with permission of the author. (c) 1993 Steven C. McConnell. All Rights Reserved. |
Subscribe in a reader
Subscribe via email