Modified:
/talk/Timeboxing/trunk/index.html
=======================================
--- /talk/Timeboxing/trunk/index.html Mon Nov 14 02:47:50 2011
+++ /talk/Timeboxing/trunk/index.html Mon Nov 14 03:02:42 2011
@@ -456,10 +456,11 @@
START OF SLIDE
-->
<div class="slide">
-<h1>Estimation</h1>
+<h1>Regular Timeboxing</h1>
<ul>
-<li>Estimation is tricky...</li>
-<li>unless based on velocity.
+<li>Estimating software is tricky.</li>
+<li>Regular timeboxing allows empirical feedback.</li>
+<li>Velocity measures progress per timebox
<ul class='incremental'>
<li>As the project progresses</li>
<li>evidence accumulates</li>
@@ -470,15 +471,24 @@
<div class='handout'>
<p>
-
-Empirical Estimation
-
-Estimatation in software is tricky, labour is not interchangable and
blending a team is an
-unpredicatable art. Predicting the
-
+Software productivity is complex and non-linear. Labour is not
interchangable,
+and the relationship between individual and team productivity is complex.
+Blending a team is an unpredictable art.
+ </p><p>
+Orthodox estimation techniques used in project planning typically break
down a complex
+project into a series of small tasks. Given high variance but unbiased
estimates (in a
+statistical sense) over a long project estimation errors will balance to
zero.
+ </p><p>
+Unfortunately, these statistical qualities are unusual in software
estimates. The
+statistics required to plan software projects goes beyond hoping errors
sun to zero.
+</p><p>
+For example, estimates
+are provisional on the current state of knowledge, which is almost always
incomplete.
+If missing information impacts a project, it is almost always in highly
negative way.
+So, to model software estimates Guassians must be skewed or estimates will
be biased.
+ </p>
Timeboxing allows an empirical alternative: velocity. For each iteration,
measure progress.
- Every iteration, use this data to estimate future progress.
-
+Every iteration, use this data to estimate future progress.
</p>
</div>