Parkinson's Law of (Planning) Meetings
In a recent iteration planning meeting we had to plan the engineering tasks required to implement the first significant chunk of our application's functionality: pricing a particular exotic financial instrument. However, we actually spent the most of the time concentrating on side issues — how to write support tools for the application, the best way to report and recover from errors, etc. — things that would be completely unnecessary if we could not make the application do something useful.
Eventually we realised that we were all discussing low priority tasks and skirting round the real problem: that we didn't actually know what pricing this instrument would involve. Once we admitted this, we were able to concentrate on how we could find out, and the rest of the planning session went smoothly.
We had fallen foul of Parkinson's Law of Meetings (also known as Parkinson's
Law of Triviality): The
time spent in a meeting on an item is inversely proportional to its
value... There is a limit to this of course, this is when the amount
concerned is trivially small.
This happens because high-value
decisions are usually complex, risky and few people at the meeting
understand the issues involved. People want to contribute to the meeting,
so they'll all give their opinions on the subjects they understand well:
the low-value, low-risk decisions.
We'll have to beware of this in future planning sessions. If we find ourselves discussing everything but an important, difficult feature we should not plan how to implement the feature and instead plan how to find out how to implement the feature.