Agilists must accept the need for revenue and budget forecasts to be taken seriously

It is easy to join the chorus of opinion that software project estimation is waste and must be eliminated. Whilst I can understand the objections to spending valuable time preparing and rationalizing a set of estimates for ill-defined features or projects, this posting explains the counter-points – why estimation is necessary, and why it is in your best interest to participate.

Thank you LeanKit for being brave enough to publish an un-popular, but important topic!

This version contains many new features and bug fixes that were reported by our early adopters. A full description of the new features can be found in the release notes, but to summarize:

Multiple project phase support – you can specify any number of project phases and apply fixed multiplier adjustments to estimates and occurrence estimates (e.g. make estimates during the ramp-up phase take a little bit longer), and have events target specific phases (e.g. have more defects reported later in the project).

New command line application – allows you to automate and integrate the simulation engine with other tools and combine the results with other analysis tools.

Customizable HTML Report Templates – you can now edit and customize all of the HTML reports using a templating language. There was a lot of feedback that you wanted these reports to be completely customizable, so we have opened up complete control.

Scrum HTML Reports now included – these missed the previous beta, all reports are now available for all simulation commands for both Agile/Scrum and Lean/Kanban.

Scrum Simulation examples – these missed the previous beta. There are now Scrum examples for every simulation command installed into the Examples folder.

Custom and Built-in Distributions – there are now over 20 built-in random number distributions, and two powerful custom distribution types that allow complete control over how random numbers are generated. This is an advanced topic that will be documented and explained in future posts.

ALPHA: Batch transfer rates for starting and completing work: To model work being started as a batch every so often, and work only being moved forward in a batch every so often, each Kanban column can specify a replenishInterval and a completeInterval. Cards will only be started after the number of simulation steps specified in the replenishInterval for a column, and will only be allowed to move to the next column or backlog after the number of simulation steps specified in the completeInterval for each column has passed. The counter resets after each trigger.