Estimates Automated
Ruby XSLT Gherkin
Switch branches/tags
Clone or download
Latest commit 42d8e48 Feb 23, 2018
Permalink
Failed to load latest commit information.
.github .github templates Feb 8, 2018
assets copyright Feb 17, 2017
bin copyright Feb 17, 2017
est Up to 2017, Happy New Year! Jan 5, 2017
features copyright Feb 17, 2017
lib email updated Jun 7, 2017
test email updated Jun 7, 2017
.0pdd.yml 0pdd config Jan 29, 2018
.gitattributes .gitattributes with IDENT Jun 22, 2015
.gitignore #1 initial scaffolding Dec 19, 2014
.pdd .pdd added Dec 22, 2016
.rubocop.yml #1 clean build Dec 19, 2014
.rultor.yml rultor coords Dec 21, 2016
.simplecov copyright Feb 17, 2017
.travis.yml no filemagic Dec 29, 2016
Gemfile copyright Feb 17, 2017
LICENSE.txt copyright Feb 17, 2017
README.md RubyMine badge changed Feb 23, 2018
Rakefile copyright Feb 17, 2017
cucumber.yml #1 initial scaffolding Dec 19, 2014
est.gemspec email updated Jun 7, 2017

README.md

Managed by Zerocracy DevOps By Rultor.com We recommend RubyMine

Build Status Gem Version Dependency Status Code Climate Coverage Status

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

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.

Best Practices

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.