As a general rule in planning its good to employ practices that mitigate against presumption influencing reality and this is well illustrated by the success that Planning Poker can bring to the software development process.

In Planning Poker the team collectively estimate by playing cards face down and once all cards are played they are turned over so that all can see that range of opinions on what the estimate should be. If anyone mentions a number or a reference to the calendar prior to the poker game the first round of cards will be anchored – the team will re-evaluate their estimates based on the number or calendar reference. Only the very best estimators can avoid this – the majority of developers fall foul of this no matter how hard they try not to – its human nature – not a personality defect.

But its not just estimates that can be anchored – other aspects of planning can succumb to the same challenges – one of the most common is the schedule.

Often a demand log of change is communicated in the first instance with the business’s view of when they would like to see items delivered – it is punctuated with “target releases” – it might look like this…

The team is anchored into thinking that release 6.03 should contain the 5 CRs indicated here before they have done any estimating. This could influence individual estimates and result in a poor expectation setting for the customer. Better to supply just the Demand Log in priority order to the development team – by all means communicate the Release Plan to the business with the caveat that the development team have yet to assess it – if necessary. Then the dev team may come back with the following…

For the purposes of illustration this is a relatively easy scenario to manage – Release 6.03 only has 4 items in it (1 less)but Release 6.04 has 7 (1 more) and over the 2 releases the same total quantity is delivered so by 22nd Sept the business will get what they expect. A more challenging scenario follows…

The assessment indicates that by 22nd Sept the business is going to have everything except CR2506. This allows them to consider what to do – maybe they can accept this position – maybe they can plan for more resource in Release 6.05 to accommodate CR 2506 – maybe some scope from an earlier CR can be reduced to shunt CR2431 up into Release 6.04 and accommodate CR2506 that way – there will be lots of options – options that would not have been discussed at all if the schedule had been anchored.