How Do You Decide How Long Things Will Take (in a SCRUM Shop)?

Subject: How Do You Decide How Long Things Will Take (in a SCRUM Shop)?
From: Geoff Hart <ghart -at- videotron -dot- ca>
To: TECHWR-L Writing <techwr-l -at- lists -dot- techwr-l -dot- com>, Yannia Vodrovich <coralfire -at- rocketmail -dot- com>
Date: Wed, 17 Jun 2009 14:57:31 -0400

Yannia Vodrovich describes the predictable chaos that arises in Agile
shops where no specific provisions are made for the writing: <<The
difficulties are obvious: I don't always know (1) how thorough the
documentation is that is already there. Sometimes I can go look and
figure it out, sometimes I can't as there is not enough time to dig or
it is not obvious as there is topic overlap; (2) I am just learning
the software which is moderately complex to complex; and (3) there are
intervening things that come up, as do things at any job, and being
new (2.5 months) I don't totally have a feel for that either.>>

I think it was Sue Gallagher who was famed in the early days of techwr-
l for her statement that "the documentation will be ready 2 weeks
after you freeze the interface". That's probably the best answer for a
micromanager who wants to know how long it will take. Point out
cheerfully that this statement applies to the documentation for each
chunk of the code, not for the software as a whole, and that you might
be able to squeeze it down to 1 week per chunk if they can guarantee
quick turnaround time reviewing and approving the docs.

When the micromanager screams, point out that there's a good reason
nobody builds houses, battleships, or factories using Agile methods,
nor will they ever: they recognize that you must design the human
interface and overall flow of a product first, make sure that it works
for the users, and only then do you figure out how to actually
implement the design. IMHO, that's the Achilles heel of (poorly
implemented? all?) Agile-like methods: they assume that the interface
will eventually evolve into something usable, rather than designing it
to be usable right from the start.

In practice, the interface design is the easy part; it's the coding
that makes the interface work that can drive programmers (and the
eventual users) mad with developing and debugging algorithms. It's
certainly true that the interface may evolve slightly as you gain more
experience with the users and how they will use your product. But if
you made an honest effort to learn this before you started the
programming, the changes should be relatively minor.

A good way to sell this approach would be the following: Point out
that the user interface can stabilize fairly quickly, and as soon as
it does, you can start documenting it. And once the interface is
stable, they can tear out and redesign the plumbing (revise the
underlying code) as often as they want without affecting your work in
the slightest, which means that your work (documenting the interface)
will be finished before their work. They won't like it, but they will
like the fact that the documentation will be ready before the product
is ready to ship instead of 2 weeks later.

Some time in the next month, I'm planning to read and review the
following book: "Designing for the digital age: how to create human-
centered products and services" (Kim Goodwin, 2009, Wiley books). If
it follows logically from the other books produced by the Cooper
Design people, it will describe a process much like what I've proposed
here, which should give it some credibility among your managers.

Geoff Hart (
ghart -at- videotron -dot- ca / geoffhart -at- mac -dot- com
Effective Onscreen Editing:


Free Software Documentation Project Web Cast: Covers developing Table of
Contents, Context IDs, and Index, as well as Doc-To-Help
2009 tips, tricks, and best practices.

Help & Manual 5: The complete help authoring tool for individual
authors and teams. Professional power, intuitive interface. Write
once, publish to 8 formats. Multi-user authoring and version control!

You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit

To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit for more resources and info.

Please move off-topic discussions to the Chat list, at:


Primer < obtaining a grant?: From: Chris Morton
Re: Primer < obtaining a grant?: From: arroxaneullman
Re: Primer < obtaining a grant?: From: Chris Morton
How Do You Decide How Long Things Will Take (in a SCRUM Shop)?: From: Yannia Vodrovich

Previous by Author: The pen is mighter than the sword
Next by Author: Plural form of appendix?
Previous by Thread: Re: How Do You Decide How Long Things Will Take (in a SCRUM Shop)?
Next by Thread: Re: How Do You Decide How Long Things Will Take (in a SCRUM Shop)?

What this post helpful? Share it with friends and colleagues:

Sponsored Ads