There are many techniques for evaluating projects from “Copy-Paste from previous” to PERT. Today I’ll talk about how I use “planning poker” and other technologies to assess projects more accurately.
Firstly, let’s mention the main difficulties in the project’s evaluation.
There are always two sides with contradicting interests: a team and a client. Teamlead stands between them. He is forced to seek a balance of opposing interests. It is impossible to overestimate the project, as the client will refuse to pay. Underestimate is also not worth it. In this case, you risk decreasing the project quality due to underfunding.
The depth of the task for evaluation is also a tricky question. Responsibilities can be discussed for a long time, then the assessment of the entire sprint will be delayed. But if you do not dig into the essence, you can miss something important that affects the deadline.
Weak and efficient developers evaluate differently. If an efficient developer evaluates the task, the weak one will not meet its deadlines with these estimates. Conversely, an efficient developer will make the job much faster than it was estimated by a weak developer. Different “social” errors are possible in the assessment, for example, when a weak developer copies the estimates of the efficiency to avoid explaining why his estimates are longer: “He said — One week for the task. I can’t say that it will take three. I’ll say at least one and a half .”
The so-called “planning poker” helps to get around this problem. The whole team participates in the assessment, not knowing who will be doing the task. The team blindly evaluates all tasks.
If the deadlines stated by team members are very different, the discussion begins. It usually turns out that the team did not notice some features that have to be implemented as part of the task. After that, everyone revotes. Now there are no claims that someone had misjudged something — everyone participated. Even if there is a mistake, no one wastes time searching for the guilty, and there is a more constructive conversation about what new factors (and how to take them into account in the future).
Additional questions to the client make evaluation more accurate. However, you can easily go too far. Some developers bombard the client with a vast number of clarification letters. This attitude is not appreciated. From the client, the number of additional questions must be minimized. However, this increases the uncertainty of the task. The balance also should be kept in this situation.
To minimize the errors in the assessments, I follow a few simple rules.
I initiate an introductory call with the client before reading the specification
During this call, I ask to tell about the problem from the business scale: who will be the end-user, how they will apply the result, what devices will be involved, what the backend looks like if it already exists, etc. After that, I can start reading the specifications.
I make a list of questions based on specifications
I try to “develop” the whole project — imagine what it will look like. The list of questions should be such that, after receiving answers, I will be able to form a reliable assessment.
The main idea here is that questions should be asked with one big chunk. Moreover, it’s often better to call on a prepared list of questions. Talking is more effective than letters. On the call, you can share the screen if this somehow clarifies the situation.
If I can’t call, I create the Google Document, where I add these questions, and the customer answers. It is a more effective way to communicate on a task than a personal chat or mail. This document can later be sent to developers who will participate in the project — they will not have to ask the same questions again.
By the way, answers must come from the person who is responsible for the project, not from the secretary. Meaningful correspondence will reduce the risk that the project parameters will change after the project ends.
If possible, I put developers into the project’s environment
Understanding how the product will be used in reality helps to improve the assessments. For example, you create software for self-payments in shops. Your developers have been sitting at the computer for 15 years and don’t understand how it all works. You bring them to end-users and ask to make a purchase specifically with this payment machine. They see that old aunt Ann is pressing two buttons simultaneously with her finger and can’t see letters on the monitor. As a result, many questions about the project disappear — the font becomes large, and confirmation of operations is added. It’s hard to imagine such problems in the head. The feeling of reality, received from a personal visit, fuels the developer during the project. Unfortunately, such an immersion is not possible in all projects.
I do not evaluate the task if the condition is “and” / “or”
For example, if it is proposed to “do authorization and registration.” I break this task down into two tasks and evaluate each of them individually. Such an assessment will be more accurate because you will not mix similar but still different entities: the better the decomposition, the more precise the result.
“Or” is even worse; it is always about a blurred specification. Accurate estimates cannot be built. Is it necessary OR not to do authorization through social networks? What if there is some specific API for the backend? If you do not know the specifics, you simply can not give an accurate assessment.
There can be no 40-hour assessment for the task
This is another variation of the previous rule. Agile recommends decomposing a project into tasks of no more than 20 hours. There should not be indivisible tasks for a week of work. In small portions, the estimate is much more accurate.
When decomposing a task, I try to log it
Firstly, it simplifies the process. I don’t recommend decomposition to be mixed with evaluation. It is better to break the entire project into components and then evaluate them at once, so as not to make your head work in two modes at once.
Secondly, the “log” of decomposition helps to explain the possible discrepancy between the assessment and reality in the future. All options that you have included in the development will be in the log. For example, you took into account authorization by login and password with a token, token renewal, etc., and the customer wanted authorization through social networks just did not write about it. Your “log” decomposition will help to protect the team from unfair claims.
I teach the team not to do the “side” tasks before they’ve completed the main
Developers spend much time on additional features. They do authorization, along the way they see that something needs to be fixed somewhere else. They start to do the side task. That’s not good. I try to bring up a reflex: “I see an accompanying task — I form a separate ticket.”
More time for testing
When evaluating, many forget about testers. However, any task, especially a difficult one, must be tested carefully. If testers find something, bugs will go to developers who have already managed to switch to a different context. They will have to dig into the topic again. And this cycle can be repeated more than once. As a rule, test assessment is given separately from developers.
I take into account the time for pair programming and specific features of the workflow
Pair programming helps to exchange experiences and motivate developers. They sit down together or share a screen, discuss the task and the tools used, and make some changes in turn. This approach pays off for the team, but for the customer, the job does not move twice as fast.
Similarly, you need to allocate time for a demonstration to the client, phone calls, correspondence, etc. In general, to fit into the assessment, the developer must work efficiently, and for this, he needs to get enough sleep, rest regularly, and be generally relaxed. Therefore, the evaluation should always be based on real work practice and not on the optimistic forecast that we will “make the five-year plan in three years.”
I am allocating time for the project deployment
There are four types of deploy platforms — development, testing, pre-production, and production. It is better to deploy these platforms at the start of the project and immediately allocate time for this. If this is not done, the synchronization of development, testing, and deployment will be disrupted.
I give a specific time. I do not make lower and upper assessments
According to the rules of marketing, when a developer says “from 4 to 12 hours,” he means “do it faster than 12 hours.” The client hears “4 hours”. If the task is completed in 11, the developer will consider that everything is fine, and the client will be dissatisfied. It happens that the client is unhappy, even if the task is completed in 4 hours and 15 minutes. Therefore, even if a minimum and maximum evaluations are calculated inside the team, only the final result is shown to the customer.
I evaluate in hours, not in days or months
Many people think that if the project is estimated at 96 hours, then it will be completed in 12 days for 8 hours, provided that only one person works on it. The situation is easily extrapolated for two developers with results of 6 days. It is a wrong estimation. Many tasks depend on each other. Firstly, developers cannot start working until a project template with all assembly systems and platforms has been created (it can take several days to deploy a working environment). Secondly, everything stops during the meetings. Thirdly, there are blocking bugs that prevent you from moving on. In other words, 96 hours at the workplace does not mean that 100% of the time (8 hours a day) will be explicitly devoted to these tasks. To use “days” evaluations, we must assume that the developer has, for instance, six working hours per day (the exact number must be determined from practice). Interaction with the team is essential to make proper time allocations.
I take into account the “team coefficient”
Usually, yesterday’s seniors go to the team leads. They evaluate tasks based on their experience, even if they have middles in their team. Perhaps the senior does not work much faster but leaves fewer bugs. Therefore, in Agile, there is the so-called “team coefficient.” It shows the difference between the optimism of the evaluator and the real life of a particular team. It is calculated only in practice: a theoretical estimate is compared with a real one for the last sprints. The better the team leader knows his team, the closer this coefficient is to 1.
Among other things, the “team coefficient” takes into account the so-called “optimism of developers” when performing the assessment. Tasks are always evaluated based on the absence of errors, the good mood of the developers, and the absence of problems in the environment. But the reality is not that safe, and there is no way to protect yourself from this. The “team ratio,” calculated over a reasonable period, allows you to take this into account.
I simplify the evaluation factors
I often see developers allocating time for bargaining. However, this is manager responsibility. For instance, the developer estimated that the task would take 8 hours, but multiplied by 2 for fidelity. Team lead doubled again, adapting to the team. And the manager made 40 out of 32 for the client. The client, seeing an estimate of 40 hours for an 8-hour task, will decide that the team does not know how to do their job.
As I noted above, at the team level, you only need to take into account the features of the team itself.
I firmly stand my ground in defending the assessment
If I know that the project will take six months, and the client expects me to evaluate it in 3, I will never name four months to “please” him.
It should be noted that sometimes there is internal bargaining. When you know that the project should be ready for the New Year, you unconsciously begin to juggle with assessments to meet the deadline. It’s quite easy to fool yourself if you have motivation for this.
Despite all this, I am ready for the assessment change
The projects live and develop. I understand that any assessment is a characteristic of the project at the moment of the assessment.
