Agile Estimation

Editor's Notes

• #5: Say you’ll do as much today (in the next iteration) as you actually got done yesterday (in the last iteration). 􀂃 Emergent properties of this rule: – We won’t habitually overestimate our abilities. We have to use actual accomplishment. If we overestimate once, we won’t be able to the next time. – If we are overcommitted, we will tend to try to finish some items in any given time period instead of half finishing them all. It is so embarrassing to tell the customer they can have zero features next time. – On the other hand, if we have a disastrous period, we are guaranteed a little breathing space to recover. – Everyone learns to trust our numbers because they are so easy to explain. – Our estimates automatically track all kinds of changes – changes to the team, new technology, dramatic changes in product direction, etc. 􀂃 The first estimate (at the beginning of the project, when there is no yesterday) is the hardest and least accurate. Fortunately you only have to do it once.
• #19: Eliminate waste : Everything not adding value to the customer is considered to be waste ( muda ). Amplify learning : Software development is a continuous learning process Decide as late as possible : As software development is always associated with some uncertainty, better results should be achieved with an options-based approach, delaying decisions as much as possible until they can be made based on facts and not on uncertain assumptions and predictions. Deliver as fast as possible : In the era of rapid technology evolution, it is not the biggest that survives, but the fastest. The sooner the end product is delivered without major defects, the sooner feedback can be received, and incorporated into the next iteration. Empower the team : There has been a traditional belief in most businesses about the decision-making in the organization – the managers tell the workers how to do their own job. In a Work-Outtechnique, the roles are turned – the managers are taught how to listen to the developers, so they can explain better what actions might be taken, as well as provide suggestions for improvements. Build integrity in : The customer needs to have an overall experience of the System – this is the so-called perceived integrity: how it is being advertised, delivered, deployed, accessed, how intuitive its use is, price and how well it solves problems. See the whole : Software systems nowadays are not simply the sum of their parts, but also the product of their interactions. Defects in software tend to accumulate during the development process – by decomposing the big tasks into smaller tasks, and by standardizing different stages of development, the root causes of defects should be found and eliminated.