Time Estimates
-
I agree that micro-estimations are a liability, but I don;t get much work at all without an upfront estimation, and I often lose there, so I'm moving toward a staggered delivery with an estimation for each phase, which is a step back toward micro-estimations.
Huge lump-of-salt caveat: I by no means claim to be an expert in agile work; just some things I've observed at various shops which claim to be "agile". We've been discussing this lately. Our boss apparently doesn't get that "agile" is an adjective for the word "development". His notion is that, once the items in a sprint are defined, they must always be completed, no matter what else (i.e., other time sucks like interviewing, prodution bugs, etc) come up. Of course, there can't be a space in the sprint planning for things like upcoming interviews. What I've discovered is that there really are only three categories of estimates: trivial (a few minutes/hours), a day or two, or "a long time". Trying to pin down anything more than a day or two is a futile exercise. For any system of that level of complexity, we can't possibly expect the business people to have thought through every possible path. Thus, there's no way that we can expect to have a complete set of requirements. To me, that's one of the strengths of agile; we have a pretty good idea of the direction we're going, and as we see it in action a little bit, we refine those requirements. But, allowing the development process to be agile means, by definition, we can't give accurate big-picture estimates. With respect to some of the other posts about management, it occurs to me that there are really only two things management needs to get right: hire competent people, and put them in a position to succeed. What does it mean to put people in a position to succeed? Pretty much analysis of the skills required to solve the problem at hand. It is not, "stick resource A on problem B and see how it goes," but rather, "problem B requires skill set X, Y, Z: find a resource with those skills." So, not a trivial problem to solve, but my experience is that most managers don't go to even that level of analysis. Of course, criticality enters into the equation. If resource A doesn't have skills X, Y, Z, and this is a high-priority, production problem, A is being put in a position to fail. If problem B is lower-priority, and A is given time to learn those skills, then A is being put in a position to succeed. But, fundamentally, it's the same problem: put your people in a position to succeed, and they will; put hem in a position to fail, and they will.
-
From today's Insider:
Seven Things I Hate About Agile wrote:
Estimating: A good, detailed estimate with task breakdowns is very reassuring if you are using it to make a budget decision or a go/no-go decision. If you already know what you want to do (eg the top stuff on your prioritized backlog), then estimating is a waste of time. It reduces productivity by wasting time. That’s true in a startup and it is also apparently true for the bigger projects in our “Scalable Agile Design Group” survey. Our analyst talked to 12 of these project leaders and came back with this summary: Some Agile textbooks recommend estimate development times for tasks, then measuring actual results against estimates. But members of this group were cautious about making estimates, and downright opposed to evaluating people and groups based on actual versus estimate comparisons. Most managers expressed one or more of these views: Estimates of software tasks are inherently unreliable. The benefits of estimates are outweighed by the time required to make them. Most developers won’t take the time to enter actual hours. Measuring people against estimates sends the wrong signals and will distract people from being flexible and innovating. Measuring people based on estimates causes them to game the system.
I think this is pretty spot on, what are everyone else's thoughts?
CPallini wrote:
You cannot argue with agile people so just take the extreme approach and shoot him. :Smile:
That pretty much sums up what I've been saying all along. But quibbles are that given the right person (me), software estimates can be fairly good. I was always stuck doing estimates and hated every minute of it. Anything I estimated got bricked into a Microsoft Project plan and our noses were held to it. I can't quite articulate how I did it, aside from just understanding the tasks and being able to imagine the volume of code it would take to create it. But that said, management never knew how to use the estimates other than to punish you if they thought you weren't keeping to them. And worse, they would then take a dependent string of tasks and they would try rearrange them to get things done faster. Again and again, I had to tell them they couldn't do that or it would all fall apart. But in reality they never wanted estimates. They would just pluck a date out of the air and pronounce it as the end date. The task list stayed the same (or got bigger) even when they would decide to move the schedule up. That was one place. At another, you'd create the estimates to figure out the project costs for the quote to the client. Well reality never means anything to the salesmen and they'd take our figure and chop it down to whatever they thought would undercut the competition to get the sale. You can argue the hardware has fixed costs and construction estimates are honored because you can see the work getting done, but the software was invisible. The cost would always remain the same, but we won't be able to bill for it. We used to joke we'd make it up in volume. The (un)amusing part would be when they thought they'd sell a duplicate of the system and try to make the money up then. But invariably the client would argue the system was already done and they'd want to pay only for the hardware, the software they expected to get for free. My experience is basically estimates don't matter. Whatever you come up with will be ignored or met with extreme skepticism as to the length (it should be shorter) and never used for any practical purpose.
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
-
From today's Insider:
Seven Things I Hate About Agile wrote:
Estimating: A good, detailed estimate with task breakdowns is very reassuring if you are using it to make a budget decision or a go/no-go decision. If you already know what you want to do (eg the top stuff on your prioritized backlog), then estimating is a waste of time. It reduces productivity by wasting time. That’s true in a startup and it is also apparently true for the bigger projects in our “Scalable Agile Design Group” survey. Our analyst talked to 12 of these project leaders and came back with this summary: Some Agile textbooks recommend estimate development times for tasks, then measuring actual results against estimates. But members of this group were cautious about making estimates, and downright opposed to evaluating people and groups based on actual versus estimate comparisons. Most managers expressed one or more of these views: Estimates of software tasks are inherently unreliable. The benefits of estimates are outweighed by the time required to make them. Most developers won’t take the time to enter actual hours. Measuring people against estimates sends the wrong signals and will distract people from being flexible and innovating. Measuring people based on estimates causes them to game the system.
I think this is pretty spot on, what are everyone else's thoughts?
CPallini wrote:
You cannot argue with agile people so just take the extreme approach and shoot him. :Smile:
An important element in this is the collection of actual time required. Once you/your company has collected a history of MHR's per line of code (or similar metric) you will have a decent method of predicting the schedule/cost of a new project. In the aerospace industry one of the companies I worked for based the estimates on lbs of airframe weight that were new and changed design. They had a thirty year history that was within +/- 20% for estimating new projects. We used the historical record as much to defend our estimates against arbitrary cuts in budget as we did to make initial estimates.
-
A rational management will understand a fundamental rule that military analysts get drummed into their heads on Day One at the War College:
The map is not the terrain.
A plan, with attached estimates of time and cost to completion, is a map; the actual enterprise of:
- Solidifying the requirements;
- Gathering all the relevant specifications for the inputs and the outputs;
- Designing the solution;
- Coding the solution and performing alpha-testing;
- Composing a beta-test procedure and contriving to get it executed by competent beta-testers;
- Coping with the screams of outraged customers to the effect that "That's not what we want;"
...is the terrain -- and a harsh, irregular, rock-strewn land it is. However, rational managements are about as rare as sensible liberals.
Possibly the best approach to the production of an engineer's estimate goes as follows:
- Take a SWAG at it.
- Double the numerical figure in your SWAG.
- Whatever the time unit in your SWAG (i.e., hours, days, weeks. months, years), replace it with the next higher one.
Thus, if your SWAG is "two weeks," publish an estimate of four months.
Why? Simply: That won't be the final schedule, and the final schedule is what really matters. The procedure above attempts to account for all the following:
- Changes in requirements.
- Management's inevitable attempt to bargain you down.
- Engineer's optimism.
- Distractions, diversions, and deflections.
- Delays in the acquisition of necessary items (e.g., file formats and test data).
- Unavoidable "learning experiences" ("What do you mean, you don't know RPG-II? Everyone knows RPG-II!")
- Everything else.
I've been using the above procedure for about thirty years, and it's served me well...because it's based on realities we'd like to wish away, but can't:
- Requirements will change.
- Management will meddle.
- We all think we're faster, smarter, and more accurate than we really are.
- There are always other things that will demand our attention.
- Nothing is ever ready when those who've promised it to you said it will be.
- So you think you know how to code a B*-tree from scratch, eh, hero? Think again!
- Murphy never sleeps.
In my experience both as an engineer and a supervisor, a competent engineer's SWAG is within 25% of exactly accurate ne
Interestingly, the "upgrade the unit and multiply by two" approach was also adopted by IBM at an early stage. I've found that in general (unless you get really lucky, which can happen) it's a fairly representative method of working it out.
-
From today's Insider:
Seven Things I Hate About Agile wrote:
Estimating: A good, detailed estimate with task breakdowns is very reassuring if you are using it to make a budget decision or a go/no-go decision. If you already know what you want to do (eg the top stuff on your prioritized backlog), then estimating is a waste of time. It reduces productivity by wasting time. That’s true in a startup and it is also apparently true for the bigger projects in our “Scalable Agile Design Group” survey. Our analyst talked to 12 of these project leaders and came back with this summary: Some Agile textbooks recommend estimate development times for tasks, then measuring actual results against estimates. But members of this group were cautious about making estimates, and downright opposed to evaluating people and groups based on actual versus estimate comparisons. Most managers expressed one or more of these views: Estimates of software tasks are inherently unreliable. The benefits of estimates are outweighed by the time required to make them. Most developers won’t take the time to enter actual hours. Measuring people against estimates sends the wrong signals and will distract people from being flexible and innovating. Measuring people based on estimates causes them to game the system.
I think this is pretty spot on, what are everyone else's thoughts?
CPallini wrote:
You cannot argue with agile people so just take the extreme approach and shoot him. :Smile:
-
A rational management will understand a fundamental rule that military analysts get drummed into their heads on Day One at the War College:
The map is not the terrain.
A plan, with attached estimates of time and cost to completion, is a map; the actual enterprise of:
- Solidifying the requirements;
- Gathering all the relevant specifications for the inputs and the outputs;
- Designing the solution;
- Coding the solution and performing alpha-testing;
- Composing a beta-test procedure and contriving to get it executed by competent beta-testers;
- Coping with the screams of outraged customers to the effect that "That's not what we want;"
...is the terrain -- and a harsh, irregular, rock-strewn land it is. However, rational managements are about as rare as sensible liberals.
Possibly the best approach to the production of an engineer's estimate goes as follows:
- Take a SWAG at it.
- Double the numerical figure in your SWAG.
- Whatever the time unit in your SWAG (i.e., hours, days, weeks. months, years), replace it with the next higher one.
Thus, if your SWAG is "two weeks," publish an estimate of four months.
Why? Simply: That won't be the final schedule, and the final schedule is what really matters. The procedure above attempts to account for all the following:
- Changes in requirements.
- Management's inevitable attempt to bargain you down.
- Engineer's optimism.
- Distractions, diversions, and deflections.
- Delays in the acquisition of necessary items (e.g., file formats and test data).
- Unavoidable "learning experiences" ("What do you mean, you don't know RPG-II? Everyone knows RPG-II!")
- Everything else.
I've been using the above procedure for about thirty years, and it's served me well...because it's based on realities we'd like to wish away, but can't:
- Requirements will change.
- Management will meddle.
- We all think we're faster, smarter, and more accurate than we really are.
- There are always other things that will demand our attention.
- Nothing is ever ready when those who've promised it to you said it will be.
- So you think you know how to code a B*-tree from scratch, eh, hero? Think again!
- Murphy never sleeps.
In my experience both as an engineer and a supervisor, a competent engineer's SWAG is within 25% of exactly accurate ne
Fran Porretto wrote:
A rational management will understand...
In the current software industry I would expect that at best a knowledgeable and rational management will understand nothing except that they shouldn't rely on software project plans. The irrational ones assume that the project plan can be done in less time often with nothing more than throwing marketing terms around.
-
A rational management will understand a fundamental rule that military analysts get drummed into their heads on Day One at the War College:
The map is not the terrain.
A plan, with attached estimates of time and cost to completion, is a map; the actual enterprise of:
- Solidifying the requirements;
- Gathering all the relevant specifications for the inputs and the outputs;
- Designing the solution;
- Coding the solution and performing alpha-testing;
- Composing a beta-test procedure and contriving to get it executed by competent beta-testers;
- Coping with the screams of outraged customers to the effect that "That's not what we want;"
...is the terrain -- and a harsh, irregular, rock-strewn land it is. However, rational managements are about as rare as sensible liberals.
Possibly the best approach to the production of an engineer's estimate goes as follows:
- Take a SWAG at it.
- Double the numerical figure in your SWAG.
- Whatever the time unit in your SWAG (i.e., hours, days, weeks. months, years), replace it with the next higher one.
Thus, if your SWAG is "two weeks," publish an estimate of four months.
Why? Simply: That won't be the final schedule, and the final schedule is what really matters. The procedure above attempts to account for all the following:
- Changes in requirements.
- Management's inevitable attempt to bargain you down.
- Engineer's optimism.
- Distractions, diversions, and deflections.
- Delays in the acquisition of necessary items (e.g., file formats and test data).
- Unavoidable "learning experiences" ("What do you mean, you don't know RPG-II? Everyone knows RPG-II!")
- Everything else.
I've been using the above procedure for about thirty years, and it's served me well...because it's based on realities we'd like to wish away, but can't:
- Requirements will change.
- Management will meddle.
- We all think we're faster, smarter, and more accurate than we really are.
- There are always other things that will demand our attention.
- Nothing is ever ready when those who've promised it to you said it will be.
- So you think you know how to code a B*-tree from scratch, eh, hero? Think again!
- Murphy never sleeps.
In my experience both as an engineer and a supervisor, a competent engineer's SWAG is within 25% of exactly accurate ne
This takes me back to Stars Trek II: The Wrath of Kahn: Spock: Admiral, if we go "by the book". like Lieutenant Saavik, hours could seem like days. Kirk: I read you captain. Let's have it. Spock: The situation is grave, Admiral. We won't have main power for six "days". Auxiliary power has temporarily failed. Restoration may be possible, in two "days". By the book, Admiral. Kirk: Meaning you can't even beam us back? Spock: Not at present. Kirk: Captain Spock, if you don't hear from us within one hour, your orders are to restore what power you can, take the Enterprise to the nearest star base, and alert Starfleet Command as soon as you're out of jamming range. Does that mean that Starfleet uses IBM's guide?
ragnaroknrol: Yes, but comparing a rabid wolverine gnawing on your face while stabbing you with a fountain pen to Vista is likely to make the wolverine look good, so it isn't exactly that big of a compliment.
-
Huge lump-of-salt caveat: I by no means claim to be an expert in agile work; just some things I've observed at various shops which claim to be "agile". We've been discussing this lately. Our boss apparently doesn't get that "agile" is an adjective for the word "development". His notion is that, once the items in a sprint are defined, they must always be completed, no matter what else (i.e., other time sucks like interviewing, prodution bugs, etc) come up. Of course, there can't be a space in the sprint planning for things like upcoming interviews. What I've discovered is that there really are only three categories of estimates: trivial (a few minutes/hours), a day or two, or "a long time". Trying to pin down anything more than a day or two is a futile exercise. For any system of that level of complexity, we can't possibly expect the business people to have thought through every possible path. Thus, there's no way that we can expect to have a complete set of requirements. To me, that's one of the strengths of agile; we have a pretty good idea of the direction we're going, and as we see it in action a little bit, we refine those requirements. But, allowing the development process to be agile means, by definition, we can't give accurate big-picture estimates. With respect to some of the other posts about management, it occurs to me that there are really only two things management needs to get right: hire competent people, and put them in a position to succeed. What does it mean to put people in a position to succeed? Pretty much analysis of the skills required to solve the problem at hand. It is not, "stick resource A on problem B and see how it goes," but rather, "problem B requires skill set X, Y, Z: find a resource with those skills." So, not a trivial problem to solve, but my experience is that most managers don't go to even that level of analysis. Of course, criticality enters into the equation. If resource A doesn't have skills X, Y, Z, and this is a high-priority, production problem, A is being put in a position to fail. If problem B is lower-priority, and A is given time to learn those skills, then A is being put in a position to succeed. But, fundamentally, it's the same problem: put your people in a position to succeed, and they will; put hem in a position to fail, and they will.
agolddog wrote:
it occurs to me that there are really only two things management needs to get right: hire competent people, and put them in a position to succeed.
Of course that only applies to delivering the product but fails to account for making money from the product. Which is something that management must also deal with.
-
From today's Insider:
Seven Things I Hate About Agile wrote:
Estimating: A good, detailed estimate with task breakdowns is very reassuring if you are using it to make a budget decision or a go/no-go decision. If you already know what you want to do (eg the top stuff on your prioritized backlog), then estimating is a waste of time. It reduces productivity by wasting time. That’s true in a startup and it is also apparently true for the bigger projects in our “Scalable Agile Design Group” survey. Our analyst talked to 12 of these project leaders and came back with this summary: Some Agile textbooks recommend estimate development times for tasks, then measuring actual results against estimates. But members of this group were cautious about making estimates, and downright opposed to evaluating people and groups based on actual versus estimate comparisons. Most managers expressed one or more of these views: Estimates of software tasks are inherently unreliable. The benefits of estimates are outweighed by the time required to make them. Most developers won’t take the time to enter actual hours. Measuring people against estimates sends the wrong signals and will distract people from being flexible and innovating. Measuring people based on estimates causes them to game the system.
I think this is pretty spot on, what are everyone else's thoughts?
CPallini wrote:
You cannot argue with agile people so just take the extreme approach and shoot him. :Smile:
When management asks for an estimate, they are actually asking for a commitment, not an estimate. (Although some would argue that they are asking for both but in a single package, but that's a quibble.) But there is a difference between an estimate and a commitment. My car mechanic doesn't come up with an estimate until he believes he knows what is wrong. Then he and I treat it as a commitment. But we don't work on cars, and the number of unknowns in a software project increase but in an unknown way as the size gets larger. Throw five people at a project, give them a scope that is small and you might be able to get your arms around an estimate. Throw 85 people at a project, put them in a new environment ("hey, Bob, we're moving to the cloud"), with technology they haven't worked with before ("your new data store will be a nosql solution we purchased from this vendor"), with a geographically separated team, and so on and you might not have any clue how many unknowns you are up against. Most unknowns add to the project rather than subtract. We can get better at estimating. But we're building custom pieces not off-the-shelf pieces. To my knowledge my mechanic has never had to build a custom part for my car.
_____________________________ A logician deducts the truth. A detective inducts the truth. A journalist abducts the truth. Give a man a mug, he drinks for a day. Teach a man to mug...
-
From today's Insider:
Seven Things I Hate About Agile wrote:
Estimating: A good, detailed estimate with task breakdowns is very reassuring if you are using it to make a budget decision or a go/no-go decision. If you already know what you want to do (eg the top stuff on your prioritized backlog), then estimating is a waste of time. It reduces productivity by wasting time. That’s true in a startup and it is also apparently true for the bigger projects in our “Scalable Agile Design Group” survey. Our analyst talked to 12 of these project leaders and came back with this summary: Some Agile textbooks recommend estimate development times for tasks, then measuring actual results against estimates. But members of this group were cautious about making estimates, and downright opposed to evaluating people and groups based on actual versus estimate comparisons. Most managers expressed one or more of these views: Estimates of software tasks are inherently unreliable. The benefits of estimates are outweighed by the time required to make them. Most developers won’t take the time to enter actual hours. Measuring people against estimates sends the wrong signals and will distract people from being flexible and innovating. Measuring people based on estimates causes them to game the system.
I think this is pretty spot on, what are everyone else's thoughts?
CPallini wrote:
You cannot argue with agile people so just take the extreme approach and shoot him. :Smile:
Estimation isn't useful if you cannot decide the priorities of your tasks and if you're working alone. Even worse, if the big planning of your project has been decided up-front, then your estimation has no impact therefore no value. Maybe in this case, you should do it anyway to know whether you're in trouble or not :-) In all other cases, estimation can be a big help to organize work, for you and your team. It's an organizational tool to get information, to help make the right choices and to give responsibility to the developers Estimation is a tool, it is not about predicting the future, but about asking questions and being able to face difficulties more efficiently when they arise. Estimation i talk about here is for small tasks (max 20 hours). That means that bigger tasks have to be slit in parts, so that actual tasks are always less or equal to 20 hours. Obviously, it doesn't apply for a whole project's estimation ; I don't go into that "reassuring" part for the managers. ABOUT PRIORITIES When priorities are not yet fixed, many parameters can influence the choice of the tasks that will be worked on first (and leaving other tasks for later, maybe never) : - the risk involved with the task (some tasks give you information and have big impact on further decisions) - the ideal date for your client (some tasks have more value if they're finished before some date) In these cases, estimations enables you to make informed decisions about priorities, therefore using your resources at their best potential. ABOUT TEAM ORGANIZATION if you work in a team, especially in self-organized team, it is useful to know when tasks will be finished : - it allows organization in merging the work with other people's work - it allows organization of limited resources (machine, expert people, customer's feedback, etc) - it allows to take decision, for instance : to split a task between people because the we'll get more value of the task if it is finished sooner - it allows to have a developer responsible for the task (volunteer) estimation is also useful as a tool to work more effectively as a team : - whether the task is big or small (which in some cases you don't know from the start), estimation forces you to know what is takes to declare the task "done" it is an agreement between the development, the testing / validating part, and the customer. ABOUT PEOPLE it helps to manage people who don't really care about the project's outcome (i have to work with such people, and since i can
-
From today's Insider:
Seven Things I Hate About Agile wrote:
Estimating: A good, detailed estimate with task breakdowns is very reassuring if you are using it to make a budget decision or a go/no-go decision. If you already know what you want to do (eg the top stuff on your prioritized backlog), then estimating is a waste of time. It reduces productivity by wasting time. That’s true in a startup and it is also apparently true for the bigger projects in our “Scalable Agile Design Group” survey. Our analyst talked to 12 of these project leaders and came back with this summary: Some Agile textbooks recommend estimate development times for tasks, then measuring actual results against estimates. But members of this group were cautious about making estimates, and downright opposed to evaluating people and groups based on actual versus estimate comparisons. Most managers expressed one or more of these views: Estimates of software tasks are inherently unreliable. The benefits of estimates are outweighed by the time required to make them. Most developers won’t take the time to enter actual hours. Measuring people against estimates sends the wrong signals and will distract people from being flexible and innovating. Measuring people based on estimates causes them to game the system.
I think this is pretty spot on, what are everyone else's thoughts?
CPallini wrote:
You cannot argue with agile people so just take the extreme approach and shoot him. :Smile:
There is an inherent flaw right there: time estimates in software are not meant to be precise individually! The point of estimates and comparing against the actual efforts is that you get an idea for the total effort required for big projects. The assumption is that the actual effort for individual tasks on average is about X-times the amount previously estimated, where X is some unknown constant based on the skill of the people making the estimates, and the complexity of the project (i. e. amount of unforeseen problems). Based on previous measurements of X, you can estimate the next project better by multiplying the sum of the estimates for the individual tasks by that factor. Of course, while in a sufficiently large project the averaging-out effect may indeed help to increase accuracy, there are still some sources of inaccuracy that remain unaccounted for, i. e. the complexity of the new project and changes in your coworkers' ability to estimate. In the end, you can only improve on your estimates if 1. You consistently take and measure estimates 2. You always work pretty much with the same team 3. The type of projects you do don't differ all that much If either of the above conditions can not be met, then estimates are indeed a waste of time.
-
Estimation isn't useful if you cannot decide the priorities of your tasks and if you're working alone. Even worse, if the big planning of your project has been decided up-front, then your estimation has no impact therefore no value. Maybe in this case, you should do it anyway to know whether you're in trouble or not :-) In all other cases, estimation can be a big help to organize work, for you and your team. It's an organizational tool to get information, to help make the right choices and to give responsibility to the developers Estimation is a tool, it is not about predicting the future, but about asking questions and being able to face difficulties more efficiently when they arise. Estimation i talk about here is for small tasks (max 20 hours). That means that bigger tasks have to be slit in parts, so that actual tasks are always less or equal to 20 hours. Obviously, it doesn't apply for a whole project's estimation ; I don't go into that "reassuring" part for the managers. ABOUT PRIORITIES When priorities are not yet fixed, many parameters can influence the choice of the tasks that will be worked on first (and leaving other tasks for later, maybe never) : - the risk involved with the task (some tasks give you information and have big impact on further decisions) - the ideal date for your client (some tasks have more value if they're finished before some date) In these cases, estimations enables you to make informed decisions about priorities, therefore using your resources at their best potential. ABOUT TEAM ORGANIZATION if you work in a team, especially in self-organized team, it is useful to know when tasks will be finished : - it allows organization in merging the work with other people's work - it allows organization of limited resources (machine, expert people, customer's feedback, etc) - it allows to take decision, for instance : to split a task between people because the we'll get more value of the task if it is finished sooner - it allows to have a developer responsible for the task (volunteer) estimation is also useful as a tool to work more effectively as a team : - whether the task is big or small (which in some cases you don't know from the start), estimation forces you to know what is takes to declare the task "done" it is an agreement between the development, the testing / validating part, and the customer. ABOUT PEOPLE it helps to manage people who don't really care about the project's outcome (i have to work with such people, and since i can
Patrice STOESSEL wrote:
=> The biggest part of "estimating a task" is used to understand it and share a common idea about what it takes to get it "done" ; this common understanding isn't optional. When this information is available, estimation time is negligible.
That is actually a very important point, and one that may make the task of estimation worth the while, regardless of the usefulness of those estimates: it forces the programmer to actually think about what needs to be done. That in itself is a good - and IMHO necessary - process. Many programmers are inclined to just dive deep into the code and start hacking away, without really thinking about what is required. Forcing them to think first may help clarify the problem and make the actual task easier to solve. Estimating also has the side effect of pointing out which parts of the task description are ambiguous or incomplete. When you think about what needs to be done, you may realize you are missing vital information. That, in turn, may be important to know for the system architect. The earlier this information can be passed on, the better the initial design will be.