The black art of estimation

How long is a piece of string?

It’s a common question and one I’ve occasionally used in reply when asked “We are building this new thing. How long will it take to provide some documentation for it?”

Estimating the amount of time it takes to write documentation is tricky as it relies on many differing, subtle, factors and, for many people working outside of a highly regimented and heavily project managed team, it tends to boil down to a mixture of guesswork and experience.

However, it’s not impossible to come up with a more reasoned estimate as long as you don’t mind doing a little planning. Although, to be frank, if you aren’t planning your work, you can probably stop reading now and go find a copy of Information Development: Managing Your Documentation Projects, Portfolio, and People.

So in the spirit of sharing, I thought I’d cover a planning aid I’ve used in the past and have, very recently, uncovered again. It’s focussed on topic based writing, so can be used whether you are single sourcing your content, or not but I should caveat that it was created with single sourcing your content in mind. This is based on a system I’ve seen elsewhere, alas I can’t recall the original source, if you know where this comes from, please let me know. I’ve adapted it for my own needs but happy to credit the original author (Hackos?).

The idea is simple enough. You break down your planned content into topics, with a topic defined as a discrete amount of information that shouldn’t take more than a couple of hours to write. Then, when you add in time for review and rewrite, you can take an educated guess at how long an ‘average topic’ takes to complete. So, for discussions sake, let’s say an average topic* takes around 5 hours to complete. Nothing revolutionary so far.

Each topic is then scored against four criteria, with the scoring used to add/subtract an appropriate level of variance:

  1. Difficulty of Topic – do you know what you are writing about or is it brand new? Is it a simple topic or something complex?
  2. Scope of Topic – Does the difficulty dictate that a lot of content is needed? Or is it a short topic of fixed content?
  3. Availability of Information – are you updating an existing document? Do you have a specification to work from? Or are you having to write from scratch?
  4. Access to SME – do you have good access to a Subject Matter Expert? Do you have limited access only? Or none at all?

Each topic is scored, from 1 (long, hard, complex) to 5 (short, easy, simple), against each criteria. An ‘average topic’ would score 3 for each criteria and won’t affect the estimate from the standard 5 hours. Scoring the topics this way allows you to factor in a level of variance, so a difficult topic with a large scope which has no information available and for which you have no access to an SME, will score lowest marks (all critera score 1) and has the highest level of variance from your standard topic estimate.

The criteria are fairly high level and you could certainly expand on these for a more granular approach but I’ve found that most issues can be assigned to one of the above criteria and that keeps the estimation as simple as possible.

The variance can then be calculated (again with an estimated time) so that you can adjust the time it takes to complete the topic, for example:

  1. Score 1 – variance of +2hrs per criteria
  2. Score 2 – variance of +1hr per criteria
  3. Score 3 – zero variance
  4. Score 4 – variance of -30mins per criteria
  5. Score 5 – variance of -1hr per criteria

The figures given above are, also, estimated. You’ll note that the higher scored (and therefore lower variance) topics don’t ‘gain’ you proportionately the same amount as you lose to the lower scored (higher variance) topics. The reality is that, no matter how simple the topic, they still take time to create (increasing the gain numbers could result in a topic taking less than zero time to create!).

So a long, complex and hard topic, with little to no information and no available expert will will score 1 across the four criteria and so add 8 hours (2hrs per criteria) to the estimated completion time for that topic, taking the estimated total for that topic to 13 hours.

Flip the example round, a short, simple topic which comes with sufficient supporting information and an SME sitting on your desk to help you write it. That topic would score 5 for each criteria, and gain you 4 hours, meaning the estimated total for that topic would drop to 1 hour.

Now, the obvious thing to do would be to create a spreadsheet for all of this, that allows you to simple add in your topics, score them against the criteria and calculate the total estimated time (and whilst it’s at it, it can add in a level of contingency too). Which is exactly what I did.

Download the estimation spreadsheet (6KB ZIP file, contains Excel Spreadsheet)

The spreadsheet is annotated to help you understand it, and includes two additional columns which let us track when a topic was added to the spreadsheet (either as part of the initial planning, identified during the review cycle, or because of a change in product scope). All of the calculations are basic arithmetic so feel free to have a poke around and try this out.

It’s not an exact system, but that’s why they are called estimates and if nothing else it helps my team plan what they are writing about which, sometimes, is more valuable than the estimates themselves.

* this is probably the most contentious part of this method and may take some refinement to arrive at a workable number.


  1. “You break down your planned content into topics, with a topic defined as a discrete amount of information that shouldn’t take more than a couple of hours to write.”

    You have been asked to estimate how long it will take to produce documentation. At this stage, you do not know what the planned content is.

    Usually, by the time that I know what the topics are, I have spent between about 3 days and 10 days a project. How do you know what the topics are without wasting much time? (I write ‘wasting’, because at this stage, all you have is an enquiry from a potential customer. You are not certain to get a contract.)

  2. Good catch Mike.

    Part of the planning of the content is figuring out what to write. Based on a specification, project plan, chats with developers and so on, you should be able to get an idea of what content is needed (the topics), and yes over time the list of topics will change and expand.

    This has the benefit of pushing you into early planning meetings, design meetings and so on. If you are estimating a contract then I’m presuming you have some information on which you can start to flesh out a content plan.

    Our process is Agile so we have to work as we go but we do start with a set of requirements and those are broken down into scenarios which, ultimately, drive the topic planning.

    Sorry I didn’t make that clear.

    Ohhh and I’m a fulltime member of staff, I already have the contract 😉

  3. Gordon, thank you for clarifying your situation.

    “If you are estimating a contract then I’m presuming you have some information on which you can start to flesh out a content plan.”

    No, the estimate comes before the content plan. A potential customer phones me and asks, “How much?”

    To produce a content plan, I must do much work to learn about the users, their problems, and the software. I want to be paid for that work. Before I do the work, the potential customer rightly wants to know how much the documentation will cost.

    To solve the dilemma, I ask the customer to tell me how large their software is, from the perspective of a user. If the potential customer can tell me how many data input screens there are, I can estimate an upper and lower cost for ‘typical’ documentation. See

    If the potential customer does not know how many user input screen there are, I cannot give an estimate. Instead, I suggest that the customer engages TechScribe on a scoping project.

Comments are closed.