
Stop wasting time getting estimates right - jakobloekke
http://agileupgrade.com/stop-wasting-time-trying-to-get-estimates-right-and-what-to-do-instead/
======
dkrich
The problem I've seen with estimates is a mix of an inconsistency of ability
mixed with a lack of experience in what is being done.

For example, I know that I can build a basic CMS system in Rails in a day
because I've done it 100,000 times. The details of the text, layout, etc.
don't take much more time to develop, so if the requirements are some
derivative of that functionality I can give a pretty accurate estimate for how
long it will take to build.

However once team size and project scope expands, you have Developer A who is
great at the assigned tasks and can finish a deliverable scoped at two weeks
in two afternoons. Meanwhile, you have Developer B who is not so great at the
assigned tasks, and requires a lot of hand-holding and assistance to build a
below-par version of what the client expects. This mixture leads to
ridiculously inaccurate estimates. What it usually boils down to on these
projects is a spreadsheet written by an out-of-touch project manager who has
to answer to a senior manager and pulls a timeframe out of thin air. A lot of
planning and documenting goes into filling about 2/3 of this timeframe, and
then the last 1/3 is spent killing yourself trying to finish a shitload of
work in a short time frame to meet the original estimate so that the PM can
show that he's really good at estimates!

I've been through this process so many times and think about it constantly and
have come to the conclusion that it's done this way because quite simply,
there is no better way that accounts for the client's demand to have a firm
estimate in place.

~~~
blt
> _What it usually boils down to on these projects is a spreadsheet written by
> an out-of-touch project manager who has to answer to a senior manager and
> pulls a timeframe out of thin air. A lot of planning and documenting goes
> into filling about 2 /3 of this timeframe, and then the last 1/3 is spent
> killing yourself trying to finish a shitload of work in a short time frame
> to meet the original estimate_

This is an accurate description of my last job using Agile practices. This was
a shrinkwrapped product too. No customer demanding estimates, in the midst of
fundamental architecture changes, and people still trying to slice-n-dice
blue-sky new product development into sprints and user stories. The estimates
were a joke and quality suffered because people rushed to get stuff done for
the 3 week sprint deadline. All because some manager wanted it. Fucking
stupid.

~~~
Spearchucker
Maybe my years (I'm over 40). I tend to ask for estimates I didn't create, and
call bullshit when I have to. People believe me, because I back my claim up
with a lot of experience and anecdote.

Also estimation and agile do work, if done with some forethought - I wrote
about that here:
[https://www.wittenburg.co.uk/Entry.aspx?id=db2d81dc-c435-42c...](https://www.wittenburg.co.uk/Entry.aspx?id=db2d81dc-c435-42ca-89a4-48273abd2cf9).

------
dpweb
At work, we are constantly hounded by non-technical business people for
estimates. They want to time/cost box you. To them - you're an expense, and an
expensive one.

My analogy would be someone asking how long it will take me to drive to my
kids' school to pick them up.

70% of the time there is no traffic and takes 35 minutes. 25% of the time
there is some wreck and takes 50-60 minutes. 5% of the time there is bad
weather and very bad traffic and takes 60-80 minutes.

So, in your mind - most of the time it takes 35 minutes, and often the devs'
answer is "35 minutes". This is where the experience comes in. The correct
answer is.. 80 minutes.

I tend to accompy this (to the particularly ignorant non-technical manager)
with various disclaimers about the 40+ year ongoing issue in est. sw
development.

~~~
omouse
That's the biggest danger with estimates, that you're being held accountable
for a padded guesstimate. One way of avoiding this is to give estimates in
ranges or with +/\- attached:

"It will take 2 days, + 5 days, - 1 day" <\-- that shows a lot of risk

"It will take 1-2 hours, + 3 hours - 0.5 hours" <\-- again, showing that
there's some risk

Or you push back and tell them to give you some time to form a better estimate
or that you will give them an estimate update as soon as you know more.

The issue is that most software developers are not trained in how to estimate
and in how to deal with these time/cost boxing scenarios. We don't attend a
class like managers do on how to deal with situations like this. We have to
learn as we go along.

I highly recommend Steve McConnell's Rapid Software Development, fantastic
book, it has a chapter on estimation and how to deal with client's and boss's
that ask for estimates.

~~~
blt
In my opinion, if someone is asking you for estimates on 1-2 hour tasks, that
person should kindly remove him/herself from the software development
industry.

~~~
gknoy
You could simply say, "I don't give estimates in under 3-hour increments,
because there are inevitably other fire-extinguishing and support activities
that interrupt even the most trivial tasks."

Sometimes I get interrupted with "Alice needs X added to Y right away", or
"Bob needs reassurance that this is working as intended in the original
ticket" \-- no problem. Other times, one might lose productivity to things
like, "Java update broke our GWT compilation toolchain completely".

It helps if your manager knows that such interruptions happen, too. I also am
a fan of overbudgeting and then revising later once I understand the problem
better.

------
fxn
I have been doing freelancing for the last 5 years without estimations or
deadlines. Has worked so great, everyone involved is focused on the task, you
iterate and concentrate on business value, quality of the solution, etc.

Nothing can be "late", there is no "I said that by X..." in your subconscious
(because you like to do what you say in the end), no absurd negotiations or
revisions, there is nothing to try to stick to, nothing artificial interfering
with working hard to get the best out of the project or task at hand.

I wholeheartedly recommend it to anyone who can work that way.

~~~
noarchy
Sounds like you haven't been crippled by Agile for these past five years.
Meaning, no middleman (perhaps one with some sort of Agile "certification")
has been gumming up the works.

This article read like it was written by a disconnected, manager-type. Not
that I don't value the efforts of a skilled project manager, but that's a
different matter entirely. Too often the _process_ becomes more important than
the _outcome_. I know the Agile evangelists will say that such managers are
doing it wrong, but in that case I'm not sure I've ever seen it done right.

~~~
jrochkind1
The ironic thing, of course, is that the original goal of 'agile', by the
people who invented it, was precisely to avoid middleman gumming up the works.
Precisely.

We are all (including many of the people who popularized the term) aware that
it hasn't always worked out that way. But that's still the goal.

------
ThomPete
I have said it before but I think it bears repeating.

Time estimations is an industrial way of thinking applied to a post-industrial
world.

In the post industrial world time isn't the problem but rather project
definition and scoping.

In the industrial world the problem was already solved (machine was built,
market often established and output depended on a few factors that could be
adjusted. Need more output add more of X)

In the post industrial world every project is about problem solving and
scoping.

To put it into comparison.

If we apply post-industrial thinking to an industrial world. It means that
each time a product needed to be done if not the factory, then the machines
would have to be developed. It will take many many years before time
estimation will die, but it will happen.

~~~
thirdtruck
_[Edit: Story changed based on feedback below.]_

Here's my analogy:

"Developer, how long will it take to acquire a vehicle that can travel a
mile?"

"That depends. Will the vehicle drive over a highway, through the sky, or dig
through a mountain?"

"That's only an implementation detail, right? Give me a ballpark estimate."

"I can call a taxi here in 15 minutes and $50. Chartering an airplane will
require two days and $2000. A granite-boring drill will take 6 months to
design, 2 years to build, and several million dollars, possibly several times
that if --"

"Geeze, no wonder no one trusts developer estimates. I'll double it and tell
them half an hour and $100, just to be safe."

~~~
IanCal
Having said that, the alternative of "estimating is a waste of time" is also
ridiculous.

"Developer, will I be able to catch the next train if I walk, or do I need to
get a taxi?"

"Estimating is a complete waste of time"

"But I just want to know if I need to spend money on a taxi. It's two miles
away and I don't have any bags, and the train leaves in one hour"

"Start thinking post-industrially"

"FFS, I just want to know how long it'll take me to get to the station!"

So what's new here? That estimating an _unknown_ task is silly? Well of course
it is! But saying estimates are useless is also daft since there are plenty of
times we know a fair amount about the problem, and knowing how long things are
likely to take is very helpful in deciding what to do next.

If someone asks me how long it'll take to add a bit more information onto a
page that we already have in the database, I can give them a fairly good
answer since it's a problem that we've done plenty of times and therefore have
a good idea about how long it's likely to take. If they want me to find new
data sources and integrate them then I can tell them we've never spent less
than X weeks doing that so we have to assume it'll take at least that long. If
X weeks doesn't seem like a worthwhile investment of time, then even this
level of estimation has been useful.

~~~
Tekhne
This analogy is flawed, and I think represents the exact problem developers
experience with non-developers. There's an underlying assumption that we know
what walking or a taxi are. We don't. In this analogy, developers would need
to invent both before giving an accurate estimate. The methods of transport
are the mechanism for delivering the result of arriving at the desired
destination. Software development projects are also about creating the
mechanism for arriving at a result. The software is bespoke almost by
definition, or you could go buy it off the shelf. Bespoke software is unknown.
It's invention. We may be able to apply past experience inventing similar
things to our estimations, but there is always some amount of uncertainty.
Sometimes there is a lot because we've never built anything like the thing
requested. We often may not even understand what is being asked for. If I
don't know what a car is, asking me how long it will take to invent one so
that you could use it to get to the train is inviting trouble.

~~~
engendered
I'll be the devil's advocate and say that a lot of software development is not
particularly novel. A lot of software development is essentially doing minor
changes to existing systems, in the same way and format as everything
existing, with nothing novel or particularly challenging.

If you're asked to add a couple of fields on a CRM form that you've worked on
for years, being able to estimate how long changing the storage, data,
business and presentation logic should be expected and easy, with high
accuracy and very little to no risk. Or maybe you're making yet another minor
derivative of a data import task that's slightly different from the hundreds
you did before. This is often why businesses demand very specific skillsets,
because while I would have no idea how long a Wordpress integration module
would take, I would bet that someone who works with it a lot would.

There are a lot of software developers who, when given such a task, will try
to make it more challenging by rebuilding everything in the process, then
throwing up their hands about the complexity involved. It's understandable why
business partners get upset about this.

There is absolutely inventive software development, but we don't make a
credible case when we lump it all in together.

~~~
thirdtruck
And a lot of these seemingly trivial, familiar tasks require far different
time than estimated (both less or more) precisely because no one went back and
rebuilt things, thereby leaving an inconsistent, incoherent spaghetti mess
behind them.

Editing code is more akin to rewriting essays than re-engineering a machine in
that way: It's going to take a lot more effort to make a 3rd grader's essay
print-worthy than one of Hemingway's.

~~~
engendered
_thereby leaving an inconsistent, incoherent spaghetti mess behind them_

Generally my experience has been that the inconsistent, incoherent mess
develops when people tasked with doing trivial changes try to "fix technical
debt" in the process, leaving you partly on the way to a "better" model, at
least until the next guy comes along. And then the next guy. Until you have a
layer cake of different approaches and technologies and philosophies,
degrading to a worse and worse state.

Look, I've been doing this for 20 years. Almost everything I work on tends to
be novel code. I'm _terrible_ at estimating, and now refuse to do it at all.
But there is a lot of self-serving, well, nonsense that we ply in this field,
justifying our failures (and the reality that most developers don't want to
learn other people's code, so they just short circuit the whole thing and
pretend it's higher ground), and the whole "technical debt" thing is one of
the most egregious. Most developers, when asked to do something to existing
code, will throw their hands up and declare it the worst code they've ever
worked with, and they can't possibly make some trivial change without
completely rewriting all of it, etc (usually somehow pulling in whatever the
pet technology of the month is...sorry, I can't change the web form without
turning it into a single-page app built on io.js and React and...). We all
tell each other this on boards that we dominate, not realizing how completely
ridiculous and transparent it really is. It's always more fun to build
something novel than to just modify things that exist.

Which is why I really think maintenance programmers are a unique and
_valuable_ breed for businesses to have. I personally have a weakness that I
always need to rebuild things. I'm terrible as a maintenance programmer, so I
simply don't do it. But there are some people who are perfectly happy adapting
to whatever they are working on, learning its idioms and unique traits, and
then competently and quickly making necessary changes without drama and
theatrics about how dire of a situation they've been put in.

To abuse the analogies that have been plied, it's being asked to drive
somewhere, and first re-building the car into an electric car, then a self-
driving car, and then deciding that you want it to be a hyperloop, and then
talking about relativity, all while the business just wanted to get from A to
B.

~~~
warfangle
> all while the business just wanted to get from A to B.

Getting the business to realize that they just want to get from A to B can
also be an issue.

~~~
briandear
Exactly this. The problem is by getting to B, the customer thinks they need to
visit C, D and E and they don't tell you until later that they also need to
visit G but only if you haven't visited H first.

The book The Nature of Software development covers this concept much better
than I could..

------
tragomaskhalos
We are in a situation where the client wants some enhancements, we know to an
order of magnitude how hard they are - ie more than a few days, less than a
month - but cannot be more accurate without actually diving in and basically
doing the work itself. But they will not green light us without an estimate.
Result = deadlock. I dream of a world where (a) customers understand that this
is an art, not bricklaying, and (b) realise that always demanding a number up
front is just going to cost them more money because the s/w folks will always
highball it to cover themselves for unexpected issues.

~~~
dustingetz
I think it's widely understood that product teams write higher quality
software than consulting teams

~~~
tragomaskhalos
Sorry if I'm being dense, but how does that relate to what I wrote above?

~~~
dustingetz
I guess I was alluding that if one is in a consulting situation where he can
no longer estimate, one possible solution may be to increase quality by being
more like a product team, and the resulting clarity of thought will help out
his estimates

------
ArturT
We recently had a discussion with a client about estimation. From the
developer point of view it's hard to predict the date because of many things
which might happen during development and we are not aware yet about them at
the moment when we need to declare the date.

Now we are using historical data to predict how many calendar days the
features scope may take with a specific confidence level.

From the client perspective dates are important because they need to
coordinate release of multiple projects and dates help them release right
stuff, in right order, in right moment on production.

Here is article about our approach [http://blog.lunarlogic.io/2015/project-
management-estimation...](http://blog.lunarlogic.io/2015/project-management-
estimation/)

------
derriz
Reasonable time cost estimation is certainly possible with software. It's not
particularly easy but you certainly have a better chance if you at least
expose yourself to the decades of hard research on the subject and not
arrogantly imagine that everyone before you started programming of flogging
your "agile approach" was an idiot and knew nothing about software
development.

Software estimating is not a particularly pleasant task - neither for
developers (they generally have no training in the area and so don't even know
how to approach the problem) nor managers (who have too little technical
knowledge).

And since 95% of development is writing in-house CRUD stuff or putting
together lightly trafficked web-pages, it's tempting to bask in ignorance and
pretend that not only is the task almost impossible anyway (and so pointless)
but that in-fact it's unnecessary. And for IS department mickey-mouse
projects, this is probably the case.

Some of us however have had to pitch fixed price tenders for large software
development projects, for example. And no, the customer isn't going to accept
that it will be done when it's done and that we should just start a few
sprints and see how it goes. And if you get the estimate wrong (too low), you
screw yourself and lose money on the project - too high and you don't even get
the contract. In this environment, you learn quickly that estimation is vital,
difficult but possible with the appropriate effort. And yes I hated doing it
the first time but it became almost satisfying after a few iterations having
gained some confidence.

This assumption that a "post-industrial", agile, folksy-anecdotal approach is
appropriate for all software development really pisses me off. It breeds
developer myopia, ignorance, self-importance and exceptionalism. Believe it or
not, engineers have estimated, planned and executed very complex systems
inside and outside of software. But it's only in software engineering do you
find clowns earnestly claiming that estimating or planning developing some
crappy CMS system is beyond human capabilities because software is so
"different" and that estimating and planning a project like the Hoover dam was
easy in comparison.

~~~
dreamfactory2
Building projects are a terrible example of predictability. They are
ultimately highly agile due to dependencies on inherently unpredictable
factors such as weather, 3rd party suppliers, industrial disputes,
archeological discoveries, legal disputes and so on.

The difference with software is that if you have done it before you should
have automated it. The great majority of programming is therefore design work.
There is an answer here which is reversing the problem and simply timeboxing
based on expected ROI and there is certainly no need for task estimation as a
component of fixed price bidding, particularly where that has a lousy
historical track record and wastes client money.

(I'm well aware that on many very large projects this is not the case and they
are run like an old-fashioned production line with humans performing well-
defined tasks - but this only illustrates the huge inefficiencies, lousy
processes, and general ignorance of software development practises as standard
in SI's.)

But aside from all that, how do you account for
[http://en.wikipedia.org/wiki/Planning_fallacy](http://en.wikipedia.org/wiki/Planning_fallacy)
?

I'd also be interested in how you apply cost estimation to debugging and other
BAU tasks.

~~~
derriz
The majority of building projects are simple and predictable - like single
domestic dwellings. Building contractors have gotten pretty good at estimating
the cost and time (or else they go bust quickly) to complete a family home
from scratch on an already serviced plot despite all the dependencies and
unpredictability you describe. Applying "agile" (i.e. not doing requirements
gathering/careful estimation/detailed planning and not having a clear goal at
the start) would be a recipe for going bust very quickly.

And the majority of development is (despite our egos) as mundane as this
really. The effort is certainly NOT spent on design work; have you ever
quantified the effort that goes into various aspects of delivering working
production software?

Re. planning fallacy, what of it? It doesn't make estimating impossible; once
you are aware of it, you account for it in your estimates. You also calibrate
your estimates with independent models and with empiricism (i.e. previous
experiences).

But the literature is extensive on this topic - I can't give a summary here
but if you are interested, there are worse places to start than with Boehm;
deeply unfashionable I know but built on (shock! horror!) empiricism and not
the rationalist (in a epistemological sense) sophistry which dominates the
thinking of "agile visionaries".

Really it's like we've regressed to a pre-scientific age in the field of
software engineering processes. Most of the debate seems about as relevant as
arguing about how many angels can dance on the head of a pin. It seem actually
observing and measuring reality went out of fashion sometime in the 90s.

~~~
dreamfactory2
> The majority of building projects are simple and predictable

The waterfall approach you are advocating can work on simple projects and
indeed it's how most digital agencies operate. However it starts to fall apart
at the seams precisely on large enterprise projects and it's no coincidence
that agile came from experience on these kind of large projects.

It's worth noting that the proponents of agile and post-industrial approaches
are not '20-somethings who don't know how the real world works' but people
with extensive industry experience such as Alan Cooper.

> The effort is certainly NOT spent on design work

While I'd certainly agree that there is a lot of boilerplate and wheel
reinvention out there, that does not represent effective development. Software
development by definition is the practise of creating automation.

The mindset of much non-technical management today is frequently one of Henry
Ford era industrialisation whereby processes are designed and carried out by
developers in a form of mechanical turk model - for example just about any
large scale outsourcing project.

However, if you take a look at a car production line today, that human work is
automated and done by robots in darkness. Efficient software development is
supposed to look like this - the developers designing and creating the
production line itself, not manually creating the end product.

We see this better use of human labor and subsequent raising of the skills bar
reflected in the job market with demand shooting up for all kinds of design
roles, from architect to UX.

> Re. planning fallacy, what of it? It doesn't make estimating impossible;
> once you are aware of it, you account for it in your estimates

That's the whole point of the planning fallacy - it occurs even when we take
it into account. There are supporting studies here and it's simply incorrect
to say that this is non-scientific.

> It seem actually observing and measuring reality went out of fashion
> sometime in the 90s.

Are you really advocating that time and motion ever turned out to be effective
at growing or even saving businesses? But seriously, agile delivery tends to
be associated with an excess of observing and measuring if anything.

------
lmm
Simpler estimates are a step in the right direction, but this article is still
advocating a very heavyweight (dare I say unagile?) process.

Time-tracking by individual story card? What would you even do with that data
if you had it? Sure you can put a precise numerical cost on how much a
"medium" story usually takes - but your estimates of feature value are never
going to be accurate enough that the difference between $6000 and $5900 is a
yes-no decision.

Going back to the points actually saves you time here - and saves you a lot of
less tangible value by avoiding timesheets (when employers introduce
timesheets, I leave. How much does hiring a new dev cost?). We got 59 points
of stories done last iteration, therefore cards cost $TOTAL_TEAM_COST/59 per
point. Done.

~~~
ebiester
The next step is to break all stories down to similarly sized stories.
Sometimes it is difficult but I have seen teams who can get it consistently
and have high confidence intervals in their times.

------
jacques_chester
The title says "Stop wasting time getting estimates right", then outlines a
number of classic ways in which estimates can be improved: give a range,
collect data, break down estimates (which is problematic by the way[0]).

The process described actually sounds a lot like the Personal Software Process
that Watts Humphrey described in the 1990s, right down to the use of proxy
values for estimation purposes.

[0] obligatory self-promoting link -- [http://confidest.com/articles/how-
accurate-was-that-estimate...](http://confidest.com/articles/how-accurate-was-
that-estimate/)

------
J_Boeg
I wrote the essay and seems it sparked a good discussion in here :-) Can't
comment on it all but the point I tried to get across was actually very
closely related to the style of thinking most of you promote in here - focus
on the outcome not the output, iterate fast and expect uncertainty in both
cost and outcome. The principles I present is trying to do exactly that (IMO)
while providing the structure to make informed decisions in terms of
prioritization and risk.

Basically - Make it short and simple for the team to estimate stuff so they
can spend their time focusing on what's important (which is NOT worrying about
whether 4 or 8 hours remain before you hit you original estimate and the
stress, drop in motivation and even potential blame games that might follow
from that) - and be disciplined enough about data to answer all the other
questions people will ask anyway. Estimating in time sucks!

And as I wrote, yes you can skip registering time on the individual user story
if you find yourself in an environment where that is doable. You will loose a
bit of data to make better informed decisions but I'll admit following the
80/20 rule that you probably should not do it if you can avoid it.

Once the structure is set up it actually is quite lightweight (especially for
the team but also the person collecting the data, both with and without the
per user story time registration) and having at least some amount of real data
does in my experience provide better and faster decisions in most contexts.

But anyway, whether you agree or you don't thank you all for discussing and
sharing. Never in a million years expected close to 13.000 users from 6
continents to visit my blog in less than 24 hours (and still rising)

BR Jesper

------
DanielBMarkham
Estimate frequently, quickly, and move on to execution. This will allow you
real-world information to make a better estimate next time. Lots of little
fuzzy guesses which trend in the right direction. I believe the complaint
about "not getting any closer to resolution" is a red herring. The value in
the exercise is creating a shared mental model, not creating COCMO VII. There
is no perfect estimation model, mainly because your team is not full of
robots.

We screw up when we get up from the IDE and start thinking of technology
development in the same way as we would using the Jquery framework. People do
not work like machines.

------
kikki
Unrelated: the first heading should be "preface" not "prefase" :)

------
jakejake
This is an interesting article to me as I'm currently making a series of
screenshot videos to document a project that we're doing at my company. It is
estimated at about 3 months and I'm recording the progress and everything to
see if we hit our goals. I thought it would be fun to post them as we go, but
for competitive reasons I'm going to hold off until we actually get it done
and then post them all.

The videos so far are turning out to be somewhat long (10 minutes reviewing
each week of the project) so I'm wondering if anybody will actually care about
viewing such a thing?

------
andyhoff
#NoEstimates to me is often an indicator of poor company culture. It
immediately makes me think of shops where there's a disconnect between
developers and the rest of the organization.

The business and product people are unable to explain why they need estimates.
Often they don't know it themselves and are just passing on the request from
their bosses or customers. They hold devs accountable for estimates even if
the requirements, priorities and teams change. They also think estimating is
free - they don't realise that producing meaningful estimates takes time and
requires a deep understanding of the code base. It also requires clear,
precise requirements which they are unable to provide.

Developers at these shops believe their single responsibility is producing
elegant code. They don't have to prioritise features based on their cost and
value; and they don't have to communicate with clients, investors or sponsors.
Many devs never learned estimating, that's why they call it an "art". They
spend forever to produce estimates that turn out to be way off, even if
requirements and circumstances don't change. The lazy way out is to say:
Estimating is a waste of time because estimates are almost always wrong.

I have seen estimating done right: It took about 5%-10% of the overall effort
spent. It helped make or break business cases, prioritise features and manage
client expecations. It raised questions that, if left unanswered, could have
resulted in massive cost explosions and unhappy customers later on.

Key cultural ingredients: \- Business and product people don't live on an
island. They understand that estimating is neither free nor instant. They work
close enough with developers to know what level of detail is necessary and
they also understand the value of refactoring, test automation, pair
programming, etc. \- Developers don't live on an island. They are involved in
product decisions and client communication, so they understand why people are
asking for estimates. They not only take pride in the quality of their code
but also in their ability to deliver features quickly \- Estimates are not
used to crucify developers, but the company culture allows an open and
forward-looking conversation when the actual effort deviates a lot \-
Estimating is seen as a skill. Becoming good at it (ie. accurate and
efficient) is a requirement to get senior dev roles \- Everybody understands
that when the world around them changes, the estimates change too

Final note: work should be estimated in line with the predictability of the
business. If your company is pivoting every 8 weeks then there's no use in
estimating 6 months out. If you have a successful app for iOS and consider
expanding to other platforms, it's probably worth estimating

~~~
ThrustVectoring
Since you want to do the features with the highest impact per unit effort
first, the units used for estimates don't matter. You could replace a time
estimate with a number between 1 and 10, and that's equivalent for
prioritization purposes.

As long as you don't let the difficulty numbers get translated back into
dates, you get the best of both worlds. You don't waste time on projects that
aren't worth doing, and there's no deadlines and estimates to cause friction.

------
jakobloekke
I want to point out, that I'm not the author of this article. It was written
by a former colleague of mine who is a very talented project manager.

------
bane
The whole game around estimates are a dirty way of dealing with other issues:

1) Can this be done before we run out of money and market opportunity?

2) How should other assets in the company be coordinated around the product.
e.g. marketing needs a lead time to produce their campaign.

3) Scopeboxing.

For #1: If you work in a big-corp, this is tied explicitly to some project
budget you have to manage. Going over that budget is a no-no. For startups,
it's the investment dollars in the company. Startups tend to be over-
capitalized for the products they tend to produce. Big-cos tend to under-fund
in an attempt to capture as much of the money as profit (especially if your
big-co is a contractor of some sort).

Estimates are intended to be converted into budget dollars (time * team-size *
burn-rate) and are critically important signalling mechanisms. No money, no
work.

For #2: Development is not the only piece of the puzzle. There might be a team
just as large and much more expensive that relies on your estimate to get
their work done so that the company runs in a reasonably coordinated fashion.
"It'll get done when it gets done" doesn't allow anybody else in the universe
to plan anything at all, and now the company has a bunch of expensive
resources sitting around doing nothing until the primadona development team
produces something. This is usually the source of adversarial and caustic
inter-departmental relationships in a company.

For #3: Good development managers learn to invert the question of estimates.
When asked "how long will this take to get done?" they answer with _" how much
time do we have? we can get this much done in that time"_ and then make that
scope a commitment. This provides much more valuable information to corporate
management, they get to set their schedule, but they also get to understand
what the product they're going to be delivering is going to look like, which
informs the teams from #2.

It also defines a clear barrier of what will be delivered and when. Scope
creep gets cleanly pushed into "the next development phase" because anything
that wasn't promised and agreed upon is outside of the current development
phase. This approach lets the development manager set expectations, and also
lets them never say "no". "Sure we can do that, I'll put that in the next
development phase" becomes the answer. Phases should be scoped to deliver a
completed working version of the product (as opposed to sprints which complete
components of a product).

If the budget runs out, or a marketing campaign is underway and development is
paused, the development manager now has a barrel full of things to scope out
for the next development phase. Taking this time to work with corporate
management and prioritize and scope out the next phase is usually a good idea.
When the time comes to resume work, the development manager can again say
"I'll deliver this much by this date".

Awesome development managers will underpromise on the scope and keep a reserve
of features as a stretch goal. If they hit the major scope, they look like a
competent and solid development team. If they hit the stretch goals they
surprise and delight everybody else in the company.

I'm not saying it's easy, but it's better than a waterfall approach and what
passes as Agile in most shops. It results in shipping products and allows
development to be better determined into overall strategy. What corp
management needs is predictability, not undetermined development cycles and
feature creep.

(#4) - To be able to say _" how much time do we have? we can get this much
done in that time"_ the devmanager needs to actually know how to estimate. A
good technique is to break the tasks down and ask the developer who's likely
to do the coding how long they'd take, add up those times and see if they fit
by the due date. If not, start tossing things. It's amazing how much you can
cut from a product and still end up with an MVP or with another version phase.

(#5) - To do all this also requires the devmanager to understand what are the
minimum tasks required to achieve a working product at the end of a phase.
Those tasks are the core of the scope. Anything else is stretch. This usually
means the devmanager needs to have a bit of domain expertise to figure this
out. It should come as a surprise, just like soda execs shouldn't run Apple,
devmanagers who don't understand what they're building shouldn't be building
it.

------
alkonaut
Estimates will always suck for 10 of them, but they work for large numbers
(you can tweak the knobs to compensate for bad estimates). My experience after
around 5000 stories and 100 man years (single project) is that we are slowly
approaching acceptable accuracy!

------
dreamfactory2
Or save yourself a lot of time by making each story worth 1 point and just
count how many stories you have. They will average out over the course of a
program (this is borne out by studies of many projects at Thoughtworks).

------
coldcode
The quality of estimates improves directly in relation to the completion date
of the project. Like forecasting the weather - looking out the window always
beats the forecast for the next week.

~~~
jeremiep
I've seen the opposite happens, the closer to the deadline the worse the
estimates. At which point the entire team is in constant crunch mode and
getting tired. This causes even more defects, which cause even worse
estimates...

One project I worked on last year saw four different authentication systems
implemented. The last one was built on the leftovers of the scaffoldings of
the previous three. We couldn't get rid of it because many other systems had
been tightly integrated into authentication at various points in time.

I would say the quality of the estimates aren't a function of the project's
completion but instead a function of the quality and simplicity of the
codebase.

------
ukigumo
I liked this article but I couldn't stop thinking "you would do well in
investing in a project manager" at every bullet point.

~~~
conradfr
Are you supposed to have a project manager in a lean or agile ? No, you're a
self-reliable and democratic driven team with a PO as a single point of
contact, with no hierarchy that will mess up this beautiful utopia.

~~~
ukigumo
Exactly! No architecture, no structure, no process, no documentation and with
some luck, no money either.

------
omouse
I've changed my mind on estimates; if you're giving a guesstimate it's your
professional responsibility to make it clear that this is a guess and to
explain that as you work or investigate the task(s) you will have a better
estimate.

If you're estimating once at the beginning of a sprint and neglecting to
update the estimate as you're working on the task or as you have new
information on the task, you are being unprofessional. It's the finer-grained
equivalent of your project manager or account manager failing to tell the
client or the boss that the project will take longer than expected after re-
evaluating risks.

At my current job, the CTO is asking for estimates in order to get a project
under control. The first estimates at the beginning of our sprints are not
fine-grained but as I work on a task I add more information and update the
estimate based on what I know. Sometimes the second and third estimate will be
a guess as well but at that point there will be some code written (or
read/investigated) which makes it easier to do an estimate.

Padding estimates is something that I'm against when you have enough
information about the task. If you're padding to account for things like
meetings or interruptions, don't do it, just log how much those are taking and
make a note of it and then everyone can see that your estimates are correct
(it did take you 5 minutes to do task XYZ) and that meetings and bullshit
interruptions are eating up lots of time. A daily standup that takes 30
minutes and then 1hr lunch and a 30min team meeting should be logged against
the project but shouldn't affect your estimate of the task.

I think the issue is that the estimate can be seen, by managers and
developers, as the end goal for the task. If you estimate at 2 hrs and you
finish in 1 hr you can just get on Hacker News or reddit for an hour. If you
estimate 0.5 hrs and it takes 10 hrs, you shouldn't be penalized as if you're
late. Updating task estimates as you gain more information about them gets rid
of that issue. If you think that 2 hr estimate was too optimistic, go ahead
and update your estimate. You can't be held accountable for a guesstimate, you
can only be held accountable for the failure or success of doing the task
itself.

If you don't know how long will it take, make it clear to your team, boss or
client that this is the case and that you will need some time to research and
to estimate.

If there's a lot of tasks that need to be done, estimating might take half a
day or a day as you go through everything. That estimation work _needs_ to
happen for any project that has its deadlines already defined (this is
frequently the case and why agile can't be improperly implemented in most
workplaces). Management needs to give you time so that you can do the
professional tasks that need to be done. You can't fix what you can't measure
and as time goes on your estimation skills will get better.

------
zobzu
id like if all my stuff took 100x1min as in the author story ;)

