Planning practices. Assessment of tasks

Hello!

Today I want to talk about several practices of assessing the tasks that have developed in our team over the years of collaboration. I hope that the article will be useful to those who are just starting their way in management, and especially to those who work on the waterfelle in the "bloody enterprise".

Effective planning depends on many different factors: the quality of the assessment, the elaboration of the details of the decision, the planning methodology used, and the correct risk assessment.

To begin, I will talk about the preparatory part of planning - the assessment of the problem by the developers. In our team, we managed, while balancing between bureaucracy and vital necessity, to develop a number of practices that allow us to turn assessments into a work plan without unnecessary delays and thoughts.

Let's start with the rules of evaluation.

We evaluate tasks according to the same rules.

We got appraisal rules after it turned out that one of the developers in the appraisal, under 1 man-day of work, implies 8 hours of continuous work without interruptions for planning meetings, tea / coffee and even sanitary and hygienic needs. Therefore, we in the team made a very simple agreement:

• evaluation is carried out in person days (in the documents we write simply “days”);
• The task for 1 person-day is solved for 1 working day. 0.5 man-days is to start in the morning and finish by dinner. This man-day includes a meeting, help to colleagues, tea with cookies, and so on;
• (for the manager) in 1 man-day about 6 hours of effective development.

Not necessarily your rules should be the same, as long as you work in the same coordinate system.

Decompose the task

Often, the developer is much easier to say: "Yes, there for a couple of weeks of work." A manager to add to the plan a task for 80 hours. However, because of this approach to planning, then there are questions like: “Tell me, how many percent of the work you need to do” and other ways to understand what progress the developer has with the task.

We set the following restrictions: any task is decomposed into subtasks lasting 0.5-3 days. Each subtask is a complete part of the functional.

Again, your team may have different restrictions. Here you need to keep a balance.

But in our experience, subtasks for more than 3 days:

• cause the effect of straightening dates ;
• demotivate the developer with a long lack of results;
• complicate the control and reduce the speed of reaction to problems.

Less than 0.5 days also have disadvantages:

• the smaller the task, the more dependencies between them;
• the smaller the tasks, the more time and attention it takes to track them.

At the same time, we immediately number the decomposition points (subtasks) - it is much more convenient to work with them in the network diagram (see below) and in the plan.

We unify the approach to decomposition

Once we faced such a situation: the assessment of the complexity of developing another team was 25% less than ours. The management was very interested in this situation - the investigation showed that our colleagues did not include in the assessment a check by the developers of the results of their development (internal smoke testing).

To avoid such situations, we added a couple more points to the rules of evaluation:

• unit testing is included in the development assessment;
• smoke testing we evaluate separately.

This item once again reminds that all team members and interested parties should work in the same coordinate system.

Evaluate task dependencies

Planning without dependencies is like a roulette game. If everything goes well, then your plan may well be successfully implemented. But if you come across a rigid interdependence of several elements of work, the plan will “go.”

Therefore, for qualitative planning, besides decomposition, information is needed on the connections between subtasks. For example, you first develop a backend, and then a frontend. Or, first you make plugs on the side of the backend, and then saw the backend and the frontend in parallel. And in fact, and in another case, there is a dependence between works. It will affect the start of work frontend.

The simplest and most understandable way to display dependencies is the network diagram. For example, one where the elements are subtasks, and the arrows show the dependencies between them.

Consider limitations

Often there are still some limitations in the task: for example, it is necessary to apply technology that is not owned by all team members. In our team, everyone owns a stack of backend, but only a few developers can develop a frontend. Therefore, in each element of the decomposition, we indicate to which technology this or that item belongs. This information on the division of work on the frontend and backend is used when planning when building a critical chain.

Risk assessment

There is an anecdote about managers who multiply developers' estimates by some empirical number. Maxim Dorofeev explains why not to do so.

Instead of playing a guessing game, we assess the risks as follows: at each point of decomposition, the developer writes down what the risks are, what their probability is and what impact they will have on the labor intensity. We call this development risk.

When planning, the manager decides how to handle the risks. And besides the risks of development, he assesses and adds managerial risks at the planning stage. For example, based on the statistics of previous projects.

On practice

In practice, in our team, when performing an assessment, the developer fills in such a simple table:

It also draws a network diagram of the following form:

Conclusion

At this assessment from the developer is completed. And the manager proceeds to work, whose task is to turn the two artifact data into a finished work plan for the task. How does this transformation, I will tell in the next section.

Thanks for attention!