Even though most methods tell you otherwise, always use a rule of thumb in software planning.
Software estimation is every software engineer’s favorite topic. Nobody wants to hack away and just see if it works.
And now the reality.
Planning in software engineering
Planning sessions are experienced by many as a necessary evil. Something you need to do so that the team boss can go to his boss to provide some numbers. These numbers are just there, so the big folks have something to discuss.
Switch. Sometimes, people honestly plan the amount of work that is necessary. Fierce discussions follow, and if there was a team before the workshop, there certainly is none left afterward.
Methods, methods, methods
There is nothing like a good new software planning method, or so they say. Get the Fibonacci number generator ready. We will do some serious planning now. The best plans have a fancy Gant chart and some confidence intervals to account for the insecurity.
Still, many plans are of by weeks, despite the best planning methods. There was just this tiny technical problem that held back delivery for four weeks. And then, testing couldn’t start because the deployment pipeline was not ready.
Missing the forest, for all the trees
Many planning sessions examine every issue for itself. The interplay of the problems, components, or procedures is seldom explored.
Often a guy (hands up if you were in this unlucky of all roles) says, well, you forgot to factor in x, y and omega. That can not work; it did not work the last time we tried it. The comparison of the current work to a similar reference work is called the outside perspective.
Risk policies are the planning’s rule of thumb.
But equally often, planning for this stuff is not even possible. We are all inside our boxes, having the same limited view. What can help here is a risk policy. Like “never buy extended warranties,” you can assume, “Never plan integration testing with less than two days.” These rules of thumb go everywhere where you have experience but face a lot of uncertainty.
You do not know what obstacles you will face, but you know that you will face obstacles.
Risk policies do not work with cutting corners.
There is often immense pressure to fit the work into a tight deadline. “You must make it work, or we can not take this client.” Who wants to be the dealbreaker in this case? The planning will cut many corners, as it is motivated by loss aversion. A risk policy is the exact opposite of this. Imagine you have a variance for the planning from 2 to 5 days, and a critical subtask like testing has the risk policy to take at least two days. This approach can not work.
Stay tuned to learn how you can still deliver value in this case.