As software developers, we have a reputation as a group for
making pretty lousy estimates. Part of that rap is unfair;
many times the requirements that we're asked to provide
estimates for are vague, and change as the work progresses.
But a large part of that reputation is true. We make
lousy estimates, and we don't seem to get much better
as we go. One problem is that the feedback loop between
the estimate and the achievement is often quite
long. When you don't begin working on a task
until weeks or months after you estimate that work,
the original mental context has been lost, making it difficult to use
feedback to learn.
Here's a way you can begin to shorten that feedback loop
right now, and put yourself on the track to becoming a
better estimator. All you need is a stack of 3x5 cards
and something to write on them with.
It works like this:
Keep a few 3x5 cards in your pocket. Before
you begin a task, pull out a card and jot down a short
description of the task on the front of the card.
Short is good--you only need enough to recognize the
task or jog your
memory later. (My latest card is titled simply "sendarticle.cgi?article=". The one I'm working on now is "PM: estimating w/ cards")
Next, take a moment to think through what "done" means for the
task, and what you need to do to get there. Now estimate
how many hours it will take you to complete the task,
and jot that down along with a confidence indicator
(e.g., "Est: 0:30 H", "Est: 14 L"). Or you can go with
a confidence range or a risk indicator. Your call.
If getting to this point with a card takes more than a minute,
it's a clue that you need to break the
task into smaller pieces. Rip up the card, break up the
task, and do a new card for each. One of the secrets to
better estimating is admitting when you've bitten off more
than you can chew, and then backing off to take smaller bites.
As you start the task, turn the card over and note the date
and start time. If you break off from the task, note the
time. And so on until you're done. The back of my most recent
card looks like
2/9/05 2/11/05
------ -------
9:15pm 8:45pm
10:45pm 9:30pm
When you're done, total up the time and write an "Actual:" number
below the estimate on the front of the card. I'd estimated 1:30 for the card above. It took 2:15, which I blame in part on the dog, who kept wandering in to my study with his squeaky toy. (Lesson learned: close study door or pad estimate with play time.)
Now, while memory is still fresh, take time to reflect
on what happened. If your estimate and actual matches, great.
More likely, you've earned an opportunity to
improve. So think: What happened? What parts did you forget to estimate?
What went harder or easier than you first thought? What could
you remember to consider the next time you're estimating a
task like this one? What about your environment interfered
with your work, and how can you either change that or
account for it in your next estimates? File the card
away. If you keep a journal, jot down some thoughts.
After doing this practice for a few weeks you may notice
improvement, and you may notice patterns, which can be fodder
for improvement. One of my patterns is a consistent
understimation for how long it will take to write a page of
complex HTML and get it looking halfway decent. Taking my
gut guestimate and doubling it works out about right.
We use this practice at work for iteration planning and tracking, though we use 4x6 cards and tack them up on boards. After doing the practice for a few months and
seeing how it improved my estimates, I adopted
it for use on home projects, using smaller cards that I can carry around in my pocket. Now, if I have have a sudden inspiration, there's always a place to jot it down.
It's a simple practice. Give it a try.
(I thought it would take 30 minutes to write this post and proof it. According to the card, it's been an hour. I've been understimating writing tasks lately...)
|
Re: Improving Your Ability to Estimate
by oakbox (Chaplain) on Feb 12, 2005 at 12:32 UTC
|
This reminds me of Buckminster Fuller's book 'The Critical Path'. The
first half is all about how you should careful record everything you
do, the second half talks about how to write down everything you do.
Making an estimate all boils down to knowing yourself. How do you
work? What is time consuming drudgery, what is exciting and engaging
for you? How GOOD are you at breaking up a project into component
parts?
I tend to go with flow charts sketched out by hand as my visual aid.
I do my best to estimate how long each of those boxes will take me to
complete. If it involves communicating with someone else or waiting
on input, I automatically double the estimate for that box.
Tally up the times and apply the Scotty factor (X 3). That is the
worst case scenario and that is the one I communicate to my
customers. The people knowledge here is spot on: Beat your estimate
and you are a hero, meet the estimate (through bad luck or unforeseen
disaster) and you are a valued member of the team who delivers on
time.
| [reply] |
|
|
++ "The Scotty factor"
Examine what is said, not who speaks.
Silence betokens consent.
Love the truth but pardon error.
| [reply] |
|
|
| [reply] |
Re: Improving Your Ability to Estimate
by stvn (Monsignor) on Feb 12, 2005 at 14:59 UTC
|
We do something very similar at my work, except we dont use index cards (in part because my handwriting is atrocious (damn that Palm graphitti!) and because I type much faster than I could ever possibly write).
When we have to estimate a task, we start out with a list of the functionality the client wants. Then we break it down into the tasks we need to take to accomplish that functionality. Then we begin estimating how long things will take.
We then have a few general rules we follow.
- Murphy's Law is always taken into account (for those who don't know, "anything that can go wrong, will go wrong")
No matter what, it is better to estimate for the worst case scenario, then the best case. You can even tell the client this if you want. I find telling this to the client is useful in illustrating how important it is that they meet their deliverables ("it will take a week if you get us the data on time, or two weeks otherwise", etc. etc.)
- Testing, testing, testing.
Our general rule of thumb is x1.5-2 for testing. This includes unit testing, integration testing and final acceptence testing.
We use to just double our estimates to allow for problems/bugs/issues. But the more we adopted TDD, the more we realized that if that time went to writing tests, then the likelihood of those problems/bugs/issues was reduced and overall quality was higher. This also can be brownie points with certain clients, they like to hear you are properly planning time for testing rather then just leaving it till the end (which basically means it won't get tested).
- System administration time.
As a programmer, I never would think about the sys-admin time to accomplish a certain task, because I never saw it as "part of the task". This actually goes for all tasks which you in particular are not responsible for. It helps to know the bigger picture basically.
Once the estimate goes off to the client it is out of your hands. However, this does not mean that everything is written in stone. Proper handling of scope creep is critical. I used to be hesitant and uncomfortable when dealing with clients on scope creep. But I have realized over the years that you get more respect from a client, and get taken advantage of less if you are hard and fast about scope creep. If explained properly, your client will understand and agree, and you can negotiate. If a client is too pushy and want's you to do it for free, then they are clearly trying to take advantage of you, and you need to respond appropriately. Always remember, your clients are not your friends. That is not to say that a particular contact at a client might not become your friend (I have worked with one guy for 3 years now and we are good friends), but when dealing with matters of business, friendship and feelings need to be left at the conference room door.
Another thing I have found is very helpful, is to make sure that client deliverables are on the schedule and those dates are enforced. Many times my estimate has been derailed because they were late, however since compliance was not enforced, my schedule was never changed, and I ended up working nights and weekends.
I say client many times here, but within reason you can substitue "account guy" or "project manager" for client (taking into account the subtleties of office politics of course).
| [reply] |
|
|
But I have realized over the years that you get more respect from a client, and get taken advantage of less if you are hard and fast about scope creep.
It sounds like you have a good grip on this, so what follows is for folks who don't.
There are several ways to handle scope creep. One is to say NO and wave contracts. Two other ways come out of Agile: Let the customer reprioritize at the beginning of each iteration, before the team estimates the work and establishes a cut-off point. Or, if the customer must make a priority change during an iteration, have a conversation that goes something like this:
"We've estimated the change that you asked for as taking 12 hours. According to the way you and I prioritized the features when we planned this round, that means that features P, D, and Q will fall off the list, unless you're like to designate 12 hours worth of other features to defer. Your call."
A likely counter at first might be
"No, you don't get it. I need the new feature and the old ones. Do it all."
to which a sane response is
"I hear that you want this new feature and everything else
we planned. And to keep the quality level commitment I made to you, I need to avoid overcommitting. If I were to ask the team to go into overtime, quality would suffer, and we'd both be paying the fallout for a long time. Neither of us really want that. So, to do this new feature, which you've said is important, we'll need to choose some other work to defer. Do you want to defer features P, D, and Q, or would you like to choose something else? Your call."
This shows your customer that you're honoring the larger agreement in a way that they can trust. It also prevents them from training you to bend over on command.
As a developer, this probably isn't a conversation you'll have with external customers. Your company probably has people who are much better skilled and practiced at such negotiations. More likely, you'll have a conversation like this with your internal customer (be that your management or product management). In dysfunctional organizations (i.e., in most companies) standing up to them can be very scary. You'll need to gauge how dangerous it is. But the consquences of not standing up with integrity and defending agreements can be very, very bleak.
| [reply] |
|
|
Excellent points. I have one comment to add.
More likely, you'll have a conversation like this with your internal customer (be that your management or product management). In dysfuncitonal organizations (i.e., in most companies) standing up to them can be very scary.
I agree, scary and politically dangerous, although not doing it can be just as dangerous. I want to share a point of view though, which took me many years (and many 80 hour weeks) to realize. In short, you probably have much more power in these situations than you realize.
I have been in many a dysfunctional organization, and 9 times out of 10 by the time the project/product manager gets too you to ask for the new feature, they have already promised it (usually because they were pressured by those above them who have promised it already as well). However here is where you need to realize that while you are the bottom of the food chain, things are not as bleak as they seems. Because what that really means is that in order for your manager to look good, and their manager to look good, etc etc on up the chain, you have to come through. In other words, you have them by the you-know-whats. Now I do not in anyway way advocate abusing this fact, however I do think it can be used (much as they are trying to use your overtime to make themselves look good). This is the time to sit up and tell your superior exactly what dws is advocating, basically "If you want this to work, you need to re-proritize". You need only stand up to your manager and in a calm clear manner explain why this will ultimately come back to haunt them (it is critical to make it about them here, not about you). It is then his/her problem to run it up the chain, but if you give them a lot of good information, reasons, examples cases, what they are asking is a bad idea, they will have plenty of ammunition.
The critical thing here is to not sound like a nay-sayer, do not be bitter, and be sure to site examples of where things went wrong and where things went right in the past. Avoid blame (always a bad idea) and try to be as cold and logical as possible. In the end if your argument is solid, you may make some headway. And if you don't you have said your peace and stood up for yourself, and hopefully things will be better the next time.
And worse case scenario, you get fired, and you go get a job at a porn site ;)
| [reply] |
|
|
|
|
This is all valid and good advise, but there's another option, too, which should not be overlooked. That is to cut scope creep off at the pass. Hit it as early as possible, before expectations are set and estimates are made. The way to do that is to deeply understand your client (internal or external, whatever) and your client's goals. Don't let someone hand you a spec or a list of feature requirements without understanding what is behind them. This is an incredibly important and worthwhile investment of time.
If you understand what your client is ultimately wanting to achieving, you will see (much of) the scope creep before they do. Also, and perhaps more importantly, if you cannot understand what they ultimately want (not what software or features they want, but what results they want), then there are several potential problems awaiting you. Not the least of which is potential miscommunication and the need for late course correction (which often programmers incorrectly call "scope creep", but is frankly their own misunderstandings coming out late). But perhaps the greatest danger of failing to understand the ultimate needs of your clients is this: If you do not really understand what they ultimately want out of the project, then you don't know whether they really understand what they want. And a client who doesn't really understand why (s)he wants something is one of the surest ways to an unsuccessful project and tons of scope creep.
But definitely not a contradiction to your points, just an addition for the record.
------------
:Wq
Not an editor command: Wq
| [reply]
[d/l] |
|
|
|
|
|
|
|
|
|
|
Re: Improving Your Ability to Estimate
by cbrandtbuffalo (Deacon) on Feb 12, 2005 at 14:14 UTC
|
Good stuff for discrete tasks. We have a similar practice, but it's a step removed from the developers; it's our time-tracking and project management software. It tracks estimates and actuals. The problem is, I don't think developers ever go back and look at the differences or review how they did with their estimates. Your suggestions above are directly aimed at being very self-aware to improve the estimates, which is a good goal. I think we've fallen into a slightly different mode where our project managers look at the past data and apply their own factor to each developer's estimates.
In other words, they learn that developer X is routinely short by half, so they double all of her estimates. In some cases we have developers who are over-cautious, so they take 75% of their estimates. Don't know if this is better or worse. I guess the developers don't have to change, but they certainly don't become any better at estimating.
My estimation problems are a little deeper with my position. I act as a technical manager on projects which means I run into two difficult estimating tasks:
- In some cases, I need to estimate time for a task without knowing who will code it. It's well documented that coders work at very different levels of productivity. I have more experience, so my estimates would be too low. So I estimate, then double it. When the project starts, we sometimes make another pass once actual developers have been assigned.
- Most of my own tasks are very ill defined, so it's difficult for me to estimate for myself. For example, one task might be 'Research bug tracking products,' or even 'Figure out how we should validate our forms.' Lately there has been some great discussion on perlmonks on validation, so I might find that and finish quickly. In other cases, it takes me a while to track down best practices on something. I still have a very hard time estimating these ill-defined tasks.
| [reply] |
|
|
I think we've fallen into a slightly different mode where our project managers look at the past data and apply their own factor to each developer's estimates.
Two red flags on this. The first you touched on: developers don't review their actuals vs. estimates, and so don't improve their estimates. If management wants it this way, it says something pretty cynical (to me, at least) about how management views programmers.
The other danger is that this gives management a bunch of out-of-context data about individual "performance". Data out of context can be used stupidly (e.g., for ranking purposes) and can lead to stupid management decisions.
When you're in the position of estimating without knowing who (else) will do the work, you're in a bad spot. When a team has data on their own past performance, and has been working to improve their estimates, I'll wager that they can give you better estimates than you can pull out of the air yourself, regardless of who on the team will actually do the work. That's been our experience. We do team estimation (or some subset of the team does for simpler tasks), and our estimate vs. actual history is a lot better than it would be if someone up the chain guessed at task difficulty.
| [reply] |
Re: Improving Your Ability to Estimate
by zentara (Archbishop) on Feb 12, 2005 at 13:43 UTC
|
It made me chuckle to read about a programmer using 4x5 cards to track time estimates. How much time would you estimate it would take to convert your card system to a computerized database? :-)
I'm not really a human, but I play one on earth.
flash japh
| [reply] |
|
|
How much time would you estimate it would take to convert your card system to a computerized database? :-)
At work the data ends up in an excel spreadsheet so that we can calculate our velocity (an eXtreme Programming thing, which is basically a measure of how much work a team can do per volume time). We use our velocity when planning forward. We only plan as much work as we've been able to complete in the prior iteration. This keeps us from getting overloaded.
| [reply] |
|
|
. How much time would you estimate it would take to convert your card system to a computerized database? :-)
But why? What benefit would be served? Not everything has to be done in bits & bytes. Sometimes pencil & paper, or post-its, or scribbles on a whiteboard, are the best tools for the job. In this case, having to go into a computer to enter the information probably DECREASES the likelihood that the data will be captured.
This time tracking task is not necessarily a nail for the computer hammer.
| [reply] |
|
|
But why? What benefit would be served?
Save some trees? :-)
I'm not really a human, but I play one on earth.
flash japh
| [reply] |
Re: Improving Your Ability to Estimate
by itub (Priest) on Feb 12, 2005 at 15:48 UTC
|
| [reply] |
Re: Improving Your Ability to Estimate
by artist (Parson) on Feb 15, 2005 at 22:56 UTC
|
As software developers, we have a reputation as a group for making pretty lousy estimates.
Being a software developer, I want to figure out how to make application work especially which are challenging. It requires testing to find out, if it is technically feasible. Now I really cannot estimate that, because it takes several attempts. I try several different ways till it works. Learning happens simulatenously in this approach. Learning and focusing in strict manners may help to estimate better.
| [reply] |
|
|
