Install it first:

$ gem install est

Run it locally and read its output:

$ est --help

Every estimate should be in its own file, with .est extension (YAML format). Here is an example of an estimate file simple.est for a simple web app:

date: 19-12-2017
author: Yegor Bugayenko
method: champions.pert
scope:
  1: basic Sinatra scaffolding
  2: front-end HAML files
  3: SASS stylesheet
  4: five model classes + unit/integration tests
  5: PostgreSQL migrations
champions:
  2:
    worst-case: 40
    best-case: 10
    most-likely: 18
  5:
    worst-case: 30
    best-case: 8
    most-likely: 16

All estimates found in a directory will be combined and a final project estimate will be produced:

$ est --dir=./est
Total: 27
2014-12-19: 27 hours by Yegor Bugayenko

Scope Champions estimating method was introduced a patent application US 12/193,010. This article explains it in more details: Revolutionary Method Of Cost Estimating. In a nutshell, there are three steps.

First, you break down the entire implementation scope into items, like it's done above, and list them under scope. Pay attention, you should list only technical code-writing tasks. Testing, requirements analysis, thinking and talking should not go into this list. Imagive, what would you do if you would be the only programmer working with the product. Imagine, you have to create the product from scratch, being the only programmer in house. It is important to keep all work items on the same level of abstraction. This means that the complexity of all items should be approximately the same.

Second, select a few items from the list (2-3), which are the most difficult to implement. They are called "scope champions". List their numbers under champions, as it's done above.

Third, estimate that champions using three-point estimating method. As in the example above, every scope champion should get three numbers. Worst case is how many hours you would spend on it, if everything would appear to be very difficult and most probable risks would happen. Best case is how many hours would this work take if everything would go easy and without any risks. Most likely is how much would it take, in a normal situation, according to your estimate.

Don't Look Back. Try not to look into previous estimates made in the project. It's tempting, but try to control yourself. Create your own estimate first and then look at others that already exist in the project.

Coding Time Only. Estimate code writing time only. Don't estimate time you would spend on discussions, thinking, modeling, diagramming, documenting etc. The estimate should count only the time you, as a single programmer in the project, would spend on code writing.

Estimate Regularly. Re-estimate the entire project from scratch regularly. In each estimate look at the project as a whole and estimate the entire scope. Not what's left, but the entire scope, as if you would need to re-create it all from scretch. Even if the project is close to its end, don't stop re-estimating it.

Change Estimators. Try to ask everybody in the project to estimate it time to time (programmers only). Changing estimators will help the project to keep numbers out of bias.

Count On Your Skills. Estimate the amount of work you would need to develop the product, not some abstract programmer. Rely on your personal skills, speed and expertise.