How do I, team leader, evaluate projects
Before talking about specific approaches, it is worthwhile to dwell on the main difficulties of the process.
There are always two sides to an assessment: a team and a client. Being between them, the team leader or manager is forced to seek a balance of opposing interests. It is impossible to overestimate the estimate, as the client will refuse to pay more. Underestimate is also not worth it. In this case, you will have to disrupt the pace of the team, risking excessive fatigue, burnout and the fact that the code goes into production unchecked.
The depth of the task for evaluation is a philosophical question. Tasks can be discussed for a long time, then the assessment of the entire sprint will be delayed. But if you do not delve into the essence, you can miss something important that affects the deadline.
Weak and strong developers act differently. If the task is appreciated by a strong developer, the weak one will not meet its deadlines. Conversely, the strong will make the task much faster than the weak appreciated. Considering the difference in speed of work, different “social” errors are possible in the assessment, for example, when a weak developer will “spy” on how much he estimates the task is strong, and set the same deadlines so as not to explain why his “estimate” is longer: “ He called the week, can not I 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, when the whole team participates in the assessment, not knowing who the task will be, and they’ll blindly evaluate it, not seeing what the colleagues are offering.
Each person scrolls a task in his head. If the terms stated by team members are very different, the discussion begins. At these moments, it usually turns out that the team did not notice any feature that would have to be implemented as part of the task. After that, everyone will re-vote. And then there were no claims that someone had misjudged something – everyone participated. Even if there is a mistake, no one will waste time searching for the guilty, there will be a more constructive conversation about what new factors have appeared and changed the alignment (and how to take them into account in the future – working on mistakes, I wrote about it in a previous article in paragraph 5).
More accurate assessment of the project helps additional questions to the client. But here you can easily go too far. Some developers are not asked for an assessment precisely because they bombard the client with a huge number of clarification letters. From the point of view of relationships with the client, the number of additional questions is best minimized, and this increases the uncertainty of the task.
Some tips on how to avoid mistakes
To minimize the error in the assessment, I follow a few simple rules.
I initiate an introductory call with the client before reading the ToR. On this call, I ask you to talk about the problem from a bird’s eye view: who will be the end user, how they will apply the result, what devices will be involved (with such permissions), what the backend looks like if it already exists, etc. After that, you can start reading TK.
Reading the ToR, I make a list of questions for the client. Studying the task, in your head you should try to “encode” the whole project – imagine what it will look like. The list of questions should be such that, after receiving answers, it is possible to form a reliable assessment.
The main idea here is that questions should not be asked gradually, but at a time. And it’s often better to call on a prepared list of questions so as not to stretch the correspondence. Still, the text conveys much less information. On the call, you can rummage the screen if this somehow clarifies the situation.
If phoning is impossible for some reason, I’m looking for a Google Document, where I’ll add these questions, and the customer answers them as time comes. This 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, it is advisable that the client responsible for the project answer the questions from the client, and not the former secretary of the director, who simply plays the role of a damaged phone. This will reduce the risk that the project parameters will change directly during operation.
If possible, I bring developers to the field. Understanding how the product will be used in reality helps to dot the “and” and improve the score. For example, software for cash registers is being developed. And your developers have been sitting at the computer for 15 years and haven’t seen the cash desk in their eyes. You bring them to end users, ask to make a purchase not somewhere, but specifically in this store. And they see that Aunt Masha is sitting there, who is pressing two buttons simultaneously with her fingers and can’t make out the letters on the monitor in glasses. As a result, many questions about the project disappear by themselves – the font becomes larger, and confirmation of operations is added. It’s hard to imagine such things in my head. And the feeling of reality received from a personal visit will fuel the developer for another year.
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”. There is no problem in breaking this point down into two tasks and evaluating 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 accurate the result.
“Or” is even worse; it is always identical to a blurred TK, from which 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.
Image: Michael Dubakov @ Medium
Estimates of 40 hours per task can not be. 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. This is useful simultaneously from two angles.
Firstly, it simplifies the process. As soon as you begin to write down thoughts on a given topic, the brain develops them with pleasure. By the way, that’s why I don’t recommend decomposition to be mixed with estimation, i.e. highlight one task and evaluate each of them immediately. It is better to break the entire project into components, fix it, 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. In fact, you have a complete description of the task being formed – what options did you consider. For example, you took into account authorization by login and password with a token, renewal of a token, etc., and the customer also wanted authorization through social networks, just did not write about it. Your “log” decomposition will help protect the team from claims that you appreciated something, but did not meet the deadlines.
I teach the team not to grab the related tasks before they are completed. Developers spend a lot of time on additional features. They do authorization, along the way they see that something needs to be fixed somewhere, and delve into this side process. I try to bring up a reflex: I saw an accompanying task – form a separate ticket. You don’t even have to run the task through the team lead or manager. When the team leader analyzes the tasks, he himself will see it and send it to work out, if necessary. So you don’t have to take anyone off from work (created a task and forgot about it), and the accuracy of the assessment will be preserved.
I am laying the time for testing. When evaluating, many forget about testers. But in fact, any task, especially a difficult one, must go through testing by living people – they should think about it, look for bugs. If they find something, bugs will go to developers who have already managed to switch to a different context. They will have to dive into the topic again. And this cycle can be repeated more than once.
Testing time is necessary. As a rule, this assessment is given separately from what the developer said.
I take into account the time for pair programming and other features of the work. Pair programming helps to exchange experiences and motivate developers. They sit down together or rummage around the screen, discuss the task and the tools used, and make some changes in turn. This approach pays off for the team, but from the point of view of the customer, the task does not move twice as fast. On projects where I worked, we did not practice pair programming constantly, but some tasks were convenient to do just that. And we took this into account at the assessment stage.
Similarly, you need to lay time for a demonstration to the client, phoning, correspondence, etc. And in general, in order to fit into the assessment, the developer must work efficiently, and for this he needs to get enough sleep, rest normally (and not the whole team on duty at the weekend on production) and not drive the work faster, faster. Therefore, the evaluation should always be based on real work practice, and not on the optimistic forecast that we will all sit down and “make the five-year plan in three years”.
I am laying time for the calculation of the project. There are four types of stands – development, testing, pre-production and production. It is better to deploy these stands at the start of the project and immediately lay down for this time. If this is not done, the synchronization of development, testing and deployment will be disrupted, which can turn into a real gag.
I do not make assessments from above and below – I call a specific term. 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 label with a minimum and maximum term is compiled inside the team (company), and then the average is calculated (there is some sense in this approach), only the final result is shown to the customer.
I name the dates only 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 to two developers, naming a rating of 6 days. But this is not true. There are many tasks that depend on each other. Firstly, developers cannot start working until a project template with all assembly systems and stands has been created (and it is created 2-3 days taking into account the wishes of the client). Secondly, everything stops when there are calls for planning. 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 devoted specifically to these tasks. For evaluation in days, we can assume that the developer does not have 8, but let’s say 6 working hours per day (the exact figure should be determined from practice).
I always ask developers how many hours a task will take from a computer (and not “after how long it will be ready”). This is a consequence of the previous paragraph. Interacting with the team as part of the assessment, it is important to correctly formulate the question.
I take into account the “team coefficient”. Usually yesterday’s seniors go to the timlids. They evaluate tasks based on their experience, even if they have middles in their team. Perhaps the senior does not work much faster, but after him there are almost no bugs. The middle is not such a quality. Therefore, in Agile there is the so-called “team coefficient”, which 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 (and the better he got his hand on the assessment), the closer this coefficient is to 1.
Among other things, the “team coefficient” also takes into account the so-called “optimism of developers” when performing the assessment. Tasks are always evaluated based on the absence of errors, satiety and good mood of the performers, and the absence of problems in the environment. But reality is replete with contingencies and there is no way to protect yourself from this. The “team ratio”, calculated over a reasonable period of time, allows you to take this into account.
Trying to lay the influence of the team, sometimes in the internal assessment they go from hours to story points. Knowing that the task will take 8 story points, they recall that last week 1 story point cost 8 hours. From this predict labor costs. But it’s easier for me to think in hours.
I do not introduce extra factors in order not to confuse other participants in the process. I often see people, conducting an assessment at the team level, laying time for bargaining in it. But the evaluation unit should not lay this stock or take into account other extraneous things. And it turns out that the developer rated the task at 8 o’clock, but multiplied by 2 for fidelity. Timlid doubled his rating again, adapting to the team. And the manager of 32 hours made 40 for the client (for an even account or just with the goal of bargaining later for 30 hours). It is more like fortune telling on coffee grounds. Yes, and the client, seeing an estimate of 40 hours for an 8-hour task, will decide that the team does not know how.
As I noted above, at the team level, you need to take into account only the features of the team itself, agreeing on who puts force majeure in the assessment (and it should be taken into account there, since we always evaluate tasks, assuming that the editor doesn’t ask for a license, developers do not run into sick leave, etc.).
Firmly stand my ground in defending the assessment. The corollary of the previous paragraph is that I always stand firm on my assessment. If I know that the project will be carried out for 6 months, and they expect me to evaluate it in 3, I will never name 4 months to “please” the customer or manager.
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 the results of the assessment so as to meet the remaining time. The brain cranks things up like that. Even if you have a list of 200 subtasks there, then they will come together so as to meet the New Year’s Eve.
Despite all this, I am ready for the assessment to change. This is normal – projects live, develop. Forming any assessment, I understand that this is a characteristic of the project at this particular time.
And the final parting word: do not force developers who do not meet deadlines to write long letters to managers on this topic. Firstly, they are likely to be shy. Secondly, the manager will probably ask something and once again distract. Thirdly, his letter of explanation will simply be lost in the correspondence. I usually ask you to write a comment on a task in Jira. Without the participation of a living person (manager) it is usually simpler and faster. And during the debriefing it will be easy to find. And timlidu plus – all tasks that are out of grades will be commented on. Again, work on bugs to improve the quality of the assessment in the future.
Posted by Eugene Wetzel (@imater)
P.S. We publish our articles on several Runet sites. Subscribe to our pages in VK, Fb, Instagram or Telegram channelto learn about all of our publications and other Maxilect news.
