PLANNING IS AN ILLUSION OF CONTROL

In December 2016, my team leader said at a daily meeting that we would have a planning meeting in 15 minutes. This was my first one.

I asked, "What is the planning meeting?"

They explained to me, "It's a meeting to estimate the duration of tasks".

I asked, "How are we going to do the meeting?"

They explained to me, "We will play planning poker. Each team member will give an independent estimate, and then we will discuss the opinions of those who gave the highest and lowest estimates."

But there was one more question I didn't dare to ask.

Why the hell would we do that?

When managers ask developers for an estimate, they forget that

1. Developers estimate their work time, not when the task will be completed

2. Developers do not consider time for analysis, QA, code review, bug fixing. Because it's impossible

3. Even if the developer adds 200% to the estimate (just in case), all that extra time will be spent. This is how Parkinson's Law works.

Days of the developer's time have just been wasted. Just to get an inaccurate and inflated estimate.

All that remains is to mark the task as non-priority and toss it back into the backlog.

When software developers try to discuss a bunch of tasks at once during planning, they just waste time.

• No one understands what needs to be done and how (except the seniors).

• No one has time to dive deep into a problem because there are a lot of problems to discuss, but the meeting is short.

• No one is motivated to put real effort into the discussion because someone else is likely to implement the task.

The only hope is that an implementer will ignore all the architectural agreements in the meeting notes and start thinking from scratch.

A manager tries to define a sprint scope. Sprint duration = 2w, number of developers = 3.

They select several tasks. The sum of their estimates = 6w. Looks like everything fits.

Wrong.

Most likely, some of these estimates are overly optimistic. Of course, the others might be overly pessimistic. But here's the thing:

An underestimated task will unpredictably take more time than it has been estimated. That's obvious.

An overestimated task will take all the time it has. Parkinson's Law works everywhere.

Work expands to fill the time allotted for its completion.

Planning errors can only accumulate.

When experts make their estimates, they do so based on their memory of how long similar problems took to resolve.

But experts are humans. Their memories are not accurate 1, they tend to be overly optimistic 2.

I would rather rely on statistics.

Use Lead Time Distribution Chart

There is software for this. At least I use Jira Flow Companion to do it.

But let's figure out how to do it manually.

1. Start tracking how many calendar days a ticket is on the board. Choose start and end points that match your production process.

2. Draw an empty diagram. The X coordinate is days on the board. Y - the number of tickets with an equal duration

3. Each time a task is completed and removed from the board, place a dot on the chart at the top of the column of tasks with the same duration.

Create more charts to be more accurate

It is better to make such a chart for each type of work and priority you have.

By type of work I mean a set of characteristics that distinguish one task from another at one glance. For example, you might have three work types: Feature, Bug, Support. The production process for all of them is different (for example, Support doesn't have the code review stage).

By priority I mean a property that significantly affects the speed at which work gets into the hands of the implementer. For example, we have two: ASAP and Standard. We start the ASAP as soon as it is on the board (we stop all other tasks with a lower priority). We do the Standard when we have time.

Now you can make predictions

To say when the specific task will be completed, you can

1. select one of your charts by type and priority

2. determine the number of dots on the chart, e.g. you have 100

3. start counting from the beginning and stop when you reach 80% of the dots

4. the day the last dot will be at is your estimate

5. now you can say "We will implement this feature ASAP, after 4 calendar days it will appear in the todo column. With 80% confidence".

You may still ask,

• how do I create a roadmap using your solution?

• how do I properly plan developer time utilization with your solution?

But neither of these tasks can be solved by planning. You will always get tremendously inaccurate results. And you use it because you don't know how else to do your job.

All I wanted to say is that planning as a practice doesn't work on a fundamental level. It only gives you an illusion of control.

There is no holistic practice that can replace planning meetings. But there is no holistic thing that can replace something as useful as a magic wand. Because all the magic wands you saw in a Harry Potter fan convention never worked. Just like planning.

But there are many better practices, better points of view. Study them, try them. There are no shortcuts.

There are no frameworks that can quickly teach you how to be smart. You have to earn smarts by experimenting with different techniques. Without it, you can't expect to ever handle real-life situations properly.

ReFERENCES