So, with the problems everything is clear. But what can be done?

Decomposition

Instead of evaluating a large task, it is better to divide it into many small ones, evaluate them, and then get the final grade as the sum of the initial grades. Thus, we immediately get many small but very useful points:

  1. We better understand the scope of work. To decompose a task, you need to read the requirements. Inexplicable places will be immediately visible. The risk of misinterpreting requirements is reduced.
  2. During the analysis of a more detailed analysis of the requirements, the thought process of systematizing knowledge automatically starts. This reduces the risk of forgetting some part of the work, such as refactoring, test automation, or the extra effort of laying out and deploying.
  3. The decomposition result can be used for project management, in case if for both processes one tool was used (this issue is discussed in more detail later in the text).
  4. If we measure the average error of the estimation of each problem obtained during the decomposition and compare this error with the error of the total estimate, it turns out that the total error is less than the average. In other words, such an evaluation is more accurate (closer to real labor costs). At first glance, this statement is counter-intuitive. How can the final evaluation be more accurate if we make a mistake in evaluating each decomposed problem? Let’s consider an example. In order to create a new form, you need to: a) write the code on the backend, b) make up the layout and write the code on the frontend, c) test and publish. Task A was evaluated at 5 hours, tasks B and C at 3 hours each. The total score was 11 hours. In reality, the backend was done in 2 hours, the form took 4, and the testing and correction of bugs took another 5. The total effort was 11 hours. Ideal to be rated. Moreover, the error in evaluating task A is 3 hours, task B is 1 hour, and C is 2 hours. The average error is 3 hours. The fact is that the errors of understating and overestimating the estimates cancel each other out. The 3 hours saved on the backend compensated for the lag of 1 and 2 hours at the front-end and testing stages. Actual labor is a random variable that depends on many factors. If you get sick, then it will be difficult for you to concentrate and instead of three hours it may take six. Or some unexpected bug will come up that will have to be searched and fixed all the day long. Or, conversely, it may turn out that instead of writing your own component, you can use an existing one, etc. Positive and negative deviations will cancel each other out. Thus, the total error will decrease.

Features and Tasks

 

At the heart of the decomposition we have is Feature. A feature is a unit of delivery of functionality that can be put on production independently of others. Sometimes this level is called User Story, but we came to the conclusion that User Story is not always well suited for setting tasks, so we decided to use a more general formulation.

One member is responsible for one feature. Someone can help him with the implementation, but only one person passes into testing. The task is also being returned to him for revision. Depending on the organization of the team, this may be a team leader or directly a developer.

Unfortunately, sometimes there are big features. It will take a very long time to work alone on such a volume. And for a long time you will have to test and implement the acceptance process. Then we change the type of task to Epic. Epic is just a very big feature. We don’t start anything more than an epic. Those epics can be just big, huge or gigantic. In any case, the epic is sent in parts (features) to the acceptance.

In order to evaluate more accurately, features are decomposed into separate subtasks (Task). For example, a feature could be the development of a new CRUD interface. The structure of tasks can look like this: “display a table with data”, “create filtering and search”, “develop a new component”, “add new tables to the database”. The structure of tasks is usually not at all interesting for business, but it is extremely important for the developer.

Evaluation in groups, poker planning

Programmers are too optimistic about the amount of work. According to various sources, undervaluation most often varies in the range of 20-30%. However, in groups the error is reduced. This is due to a better analysis and different points of view and evaluating temperament.

The most common practice with the growing popularity of Agile was the practice of “poker planning”. However, there are two problems associated with group assessment:

  • Social pressure
  • Time costs

Social pressure

In almost any group, the experience and personal effectiveness of the participants will vary. If the team has a strong team / tech – lead / lead programmer, other members may feel uncomfortable and deliberately underestimate their grades: “Well, how can Mark do it, and me not? I can do that too!”. The reasons may be different: the desire to seem better than he or she really is, competition or just conformism. The result is one: group assessment loses all its advantages and becomes individual. Team lead gives marks, and the rest just agree.

There are several main recommendations:

  • Most ratings are underestimated. Can’t choose between two ratings? Take the bigger one.
  • Not sure about the rating – throw out the card “?” or a big rating. Perhaps almost never works.

Always compare plan and fact. If you are not sure, give an estimate two times higher than what you think. Started to overstate? Multiply in your mind by one and a half. After a few iterations, the quality of your grades should improve significantly.

Time costs

You know the phrase “Do you want to work?” Make a meeting!” It was not enough, that one programmer tries to predict the future instead of writing code. Now the whole group does it. In addition, working out a decision in a group is a much longer process than making individual decisions. Thus, group evaluation is an extremely costly process. It is worth looking at these costs from the other side. First, in the evaluation process, the group is forced to discuss the requirements. This means that you have to read them. Already not bad. Secondly, let’s compare these costs with those that the company will have due to underestimation of the project.

If we consider investment in the evaluation as an investment in the making of management decisions, then they stop to seem so costly. Group size is another thing. Of course, it is not necessary to force the whole team to evaluate the entire amount of work. It is much more reasonable to divide the task into micro-services and provide the teams with autonomy. And at a higher level, use the estimates obtained by each team to create a project plan. And this smoothly brings us to the topic of the next article.