One cannot avoid unseen forces in effect when agile in place. That said, when practicing Agile you must be aware of the “Laws” at work. We’re not necessarily talking about the ones that bring about the police, judge and jury if you break them. When looking at Parkinson’s Law, we’re talking about a law that you can’t avoid whether you like it or not.
What Is Parkinson’s Law? And How it Works
Parkinson’s Law is all around us, and it’s part of our everyday lives, but since we find it to be a natural progression of what is constant in our day-to-day, we think nothing of it. So it’s time to wake up! What about Parkinson’s Law? Well it states that “work expands so as to fill the time available for its completion.” That is to say, we usually think of estimating work (in whatever form you decide), to the extent that we know about the available resources. If you were asked to go fill a cup of coffee for someone, or yourself for that matter, would you be likely to fill it to the top, or just halfway. Sure we can think of the times we would fill it halfway, but more often than not, we fill it to the top. So we’re not saying Parkinson’s Law is an absolute or that it happens 100% of the time, but it does certainly happen often.
How Can You Spot Parkinson’s Law at Work?
Usually when we estimate during planning sessions, we may be lead to fill up the time we have to do something, with the time we have available. So let’s think of this on 2 levels. In sprint planning we naturally fill in the Sprint with the story points based on our average velocities from previous sprints. Now that’s where Parkinson’s Law works well. And that’s actually why we use story points, to remove the concept of time, and falling into traps, not just Parkinson’s Law. But say for instance, someone asked you to estimate a Story (or Use Case) in real time, and imagine that you were somewhat influenced previously (or at that very session), where someone said in low-key that you had about 3 days to do it. It may very well take 2 days to complete the work, but are you being rational at that point? Or are you going to really take some time to figure out how long it may actually take? Any task, no matter how simple or compact, deserves a fresh set of thoughts and ideas to assess it’s level of complexity. Reason being, you wouldn’t want to over (or under) estimate a task if it truly wasn’t the time it could’ve actually taken.
What Are the Consequences?
Assume you estimated every task you had with what your colleagues told you is the “standard.” You could very well just go with the “standard” times, or better yet you may give yourself the excuse that you didn’t have the time to run through the actual requirement, or the task seems so simple, it shouldn’t take longer than the “standard.” Think about what this means with regard to the overall value of a project. The concept behind which sprint planning, depends on your flexing the metaphorical estimation muscles. The more you practice, the better you will become at being increasingly accurate. With unrealistic estimates, you may actually inflate budgets, and the perception of waste will be greatly increased, and the level of competitiveness drops. Many teams can fall victim with this Parkinson’s Law at work, when many tasks that shouldn’t take very long, end up being logged with double or triple the time it really took. You may be able to get away with it sometimes, but what if your client isn’t that naive?
[Image courtesy of stockimages at FreeDigitalPhotos.net]
Share this:
This work is licensed under a Creative Commons Attribution 4.0 International License.
