Estimating the time you need to build a widget is relatively straightforward. Estimating the time you need to build something based on knowledge and experience is another matter. It isn’t easy. Sometimes I get it right, sometimes I get it wrong (and really wrong). Here are a few tips I’ve picked up over the years.
- Use prior experience. While no two knowledge tasks are exactly the same, something similar can offer a general idea if it might require five minutes or five hours.
- Make records. As you build experience working on tasks of a certain type, you not only build experience in completing those tasks, there’s now data to back you up. You don’t need to make intricate time coded entries for each subtask, however, I’ve found that details for different types of work (such as research, drafting, editing, debugging) help me later.
- Review. Did that surprise you? Reviewing can help you figure out how long the task took compared to estimates. This can also help you look into micro improvements to improve next time as you build an accurate average picture of how long certain tasks will take.
For example, the drafting of a blog post may change depending on if it is a topic you need to research, or if it’s on a topic you are very familiar about. However, with your records and review, you may learn that you tend to take approximately the same amount of time to format and prepare it to be published. This also lets you build enough time if you’re drafting to a deadline.
It isn’t easy to estimate time. However, building this skill can help most when you are working to a tight deadline. Earlier this week John Scalzi admitted he wrote his newest novel, The Consuming Fire in two weeks. It wasn’t easy, it isn’t recommended, but his past experiences provided him all the skills to make it happen.