Evidence-based scheduling: Difference between revisions

Revision as of 00:52, 11 February 2009

Latest revision as of 07:02, 15 July 2022

(36 intermediate revisions by 24 users not shown)

Line 1:

{{Short description|Software estimation based on data collection and analysis}}

Evidence-based Scheduling is a software estimation approach created by Joel Spolsky, a [http://www.amazon.com/Joel-Software-Occasionally-Developers-Designers/dp/1590593898/ commentator] on software engineering principles.

{{Use dmy dates|date=October 2017}}

{{refimprove|date=October 2017}}

{{Evidence-based practices}}

'''Evidence-based scheduling''' is a [[software estimation]] approach created by [[Joel Spolsky]], a commentator on software engineering principles. Evidence-based Scheduling is based on at least two core ideas: including all time spent, and using a Monte Carlo completion date prediction method. Evidence-based scheduling is an example of an [[evidence-based practice]].

==Including all time spent==

The previous page describing the approach was deleted on the grounds of it being blatant advertising (Spolsky's company sells a tool which includes it as a feature). It was recreated on the grounds that this technique is an important software engineering technique for the [http://stackoverflow.com/questions/8876/evidence-based-scheduling-tool community] and Spolsky's original blog posting <ref name="EBS">[http://www.joelonsoftware.com/items/2007/10/26.html], Evidence-based Scheduling blog posting 2007</ref> of the idea is sufficiently clear for anyone to implement it.

One of the core ideas of Evidenceevidence-based Schedulingscheduling, that adds to the normal estimation practices, is the idea of '''including all time spent, regardless of relevance'''.

Most people, when estimating, measure the time they actually spend on a project -– classic Time Accounting categories such as cited in McConnell's ''Software Project Survival Guide''<ref name="SPSG">[httphttps://www.amazon.com/Software-Project-Survival-Guide-Practices/dp/1572316217], Software ProjeectProject Survival Guide]</ref> do not allow for accounting for non-project activities. WhilstWhile McConnell goes on to include less obvious activities such as holidays, sick days and project support, he and most others identify such as activities to be separately recorded.

One of the core ideas of Evidence-based Scheduling, that adds to the normal estimation practices, is the idea of '''including all time spent, regardless of relevance'''.

However, recording and attempting to budget for secondary activities often leads to political pressure to drop such activities. In practice, people find themselves unable to avoid them and compensate by working overtime. Similarly, as Spolsky points out,<ref name="EBS">{{Cite web|url=https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/|title=Evidence Based Scheduling|date=26 October 2007|website=Joel on Software}}</ref> your bosses' stories about his fishing trips, or model helicopter, are both a time-sink and politically dangerous to put on a time-reporting system.

Most people, when estimating, measure the time they actually spend on a project - classic Time Accounting categories such as cited in McConnell's ''Software Project Survival Guide''<ref name="SPSG">[http://www.amazon.com/Software-Project-Survival-Guide-Practices/dp/1572316217], Software Projeect Survival Guide</ref> do not allow for accounting for non-project activities. Whilst McConnell goes on to include less obvious activities such as holidays, sick days and project support, he and most others identify such as activities to be separately recorded.

The key insight in evidence-based scheduling is that the only thing which needs measuring is the actual delivery of tasks. Over time, it is assumed that all other distractions will average out. For the purposes of estimation, variations due to interruption will show up as inaccuracies in estimation and will be compensated for by statistical analysis. The reasons for anomalies may come out if the organisation wishes to dig deeper into why people have irregular estimates.

Recording and attempting to budget for secondary activities often leads to political pressure to drop such activities. In practice, people find themselves unable to avoid them and compensate by working overtime.

The appeal of this idea is simplicity -– the amount of evidence to be created is simply the elapsed time between completing tasks and, another vital point, time spent debugging is applied back to the original task.

As Spolsky points out <ref name="EBS" />, your bosses' stories about his fishing trips, or model helicopter, are both a time-sink and politically dangerous to put on a time-reporting system.

==Monte Carlo method==

The key insight in Evidence-based Scheduling is that the only thing which needs measuring is the actual delivery of tasks. Over time, it is assumed that all other distractions will average out.

Another core idea is the use of the [[Monte Carlo method]] to predict project completion dates. This method evaluates how reliable previous estimates have been. Instead of a single completion date, the method results in multiple possible completion dates, each with an associated probability of being correct.

==References==

For the purposes of estimation, variations due to interruption will show up as inaccuracies in estimation and will be compensated for by statistical analysis. The reasons for anomalies may come out if the organisation wishes to dig deeper into why people have irregular estimates.

{{reflist}}

{{Evidence-based practice}}

The appeal of this idea is simplicity - the amount of evidence to be created is simply the elapsed time between completing tasks and, another vital point, time spent debugging is applied back to the original task.

[[Category:Software engineering costs]]

{{Reflist}}

[[Category:Evidence-based practices]]

{{software-eng-stub}}