What methods do developers use to evaluate tasks?

Hi all! The theory required to start development is very extensive. Some specialists (backend developers in Java and other languages) have more of it, while others (for example, frontend developers in JavaScript - React Native) have a little less. However, both of them must have a large stock of not only technical, but also “organizational” knowledge. This “organizational” knowledge is one of the intersection points for frontend and backend developers. Today I want to talk about one aspect of such non-technical, organizational knowledge - about task assessment (estimation). And since I worked only in the Agile methodology (which in fact is considered the most popular), in its subpart, Scrum , I will consider task assessment in the context of Scrum . I’ll say right away that assessment, also called estimation, is difficult. For me personally as a developer this is one of the most difficult/undesirable aspects of the job. There are many different factors to consider that can influence the assessment of a task. At the same time, plans for further development will be based on your forecasts.

What if you don't get the rating right?

If a developer spends many more hours on a task than will be spent in the end, it may seem that he is not the best specialist, because the estimate was very inaccurate. So to speak, a finger in the sky. At the same time, if the developer does not invest in the predicted time, he jeopardizes the customer’s plans to release the product/new feature. This is a business, and business means money, and few customers will like such a puncture. This is actually why I don’t like estimation, because sometimes it’s so difficult to determine the exact time for completing a task.

How is time assessed?

As a rule, estimation is carried out in hours or story points. Personally, I am much closer to the evaluation process in story points . If a watch is something physical, then something that can be mistaken, story points are a little about something else, more abstract. Typically, software development teams give estimates in time format: hours, days, weeks, months. Such time estimates are based primarily on personal experience, guesswork, or intuition. In this case, the developers simply look at the task and voice an estimate of how long it would take them. As a result, they are very rarely accurate, because there are too many factors that can affect the deadline for completing the work. Therefore, many teams working according to the Agile methodology use story points. Let's figure it out.

What are Story points

A story point is a unit of measurement that expresses an assessment of the total effort that is necessary to fully implement a certain area of ​​work (functionality). That is, this is such a relative complexity . Teams assign story points based on the complexity of the work, the scope of the work, and the risk or uncertainty. Typically, these values ​​are assigned to more efficiently break down work into smaller parts, thereby eliminating uncertainty. Over time, this helps teams understand what they can achieve in a given period of time and helps them plan the next areas of work more accurately. This may seem completely counterintuitive to you, but this abstraction is actually quite useful: it pushes the team to make tougher decisions about the complexity of the work. Let's look at some reasons to use story points in planning:

• estimation inaccuracy in time intervals can be avoided;
• Unlike estimating over time, overhead costs can be better taken into account: communications between team members and the customer, various team discussions and planning, as well as unforeseen situations;
• Each team will grade work on a different scale, which means their speed (measured in points) will be different;
• By defining a scale for assigning each story point, you can quickly distribute points without much controversy.

How NOT to use story points

Unfortunately, story points are often used for other purposes. Story points can be flawed when they are used to evaluate people, define detailed deadlines and resources, and when they are mistakenly taken as a measure of performance. Instead, teams need to use them to understand the volume/complexity of work in each task and to prioritize. It is possible that the parts that are rated as more difficult should be done first so that they can be completed before the end of the sprint , but the easier ones can be pushed back to later. Let me remind you what a sprint is in the context of the Scrum methodology: How long this time period is determined at the beginning of development by agreement between the team and the customer. This could be a period of two weeks or a month, or any other period. As a rule, task estimation is carried out at the beginning of the sprint in order to plan the possible amount of work completed by the end of the sprint, when the completed work is delivered to the customer. It helps you see your progress in product development, receive feedback from the customer and adjust the development of the project according to the customer’s vision. But still, we digress a little: let’s get back to the estimation. Evaluating tasks by just one developer would be too subjective. Therefore, as a rule, this is team work. There are quite a few techniques for team assessment. Today we will look at the most used of them - Scrum poker . This technique requires a manager who will be someone like the leader of this Scrum poker . This could be a person specializing in Scrum Master , or PM .

What is Scrum Poker

Scrum poker - or planning poker - is an evaluation technique that is based on reaching an agreement. Mainly used to assess the complexity of the work ahead or the relative volume of tasks to be solved during software development. I’ll note right away that Scrum poker is a common practice in development, and you definitely need to know what kind of beast it is. For this process, we usually use some kind of application or website that allows us to organize a team assessment of a particular task. How does this happen? The team takes a backlog item (new task, functionality), briefly discusses possible pitfalls and other nuances associated with it. Each participant then chooses a card with a number that represents their difficulty rating. Oh, and when estimating, it is not the usual series that is used, but Fibonacci numbers . Fibonacci numbers are so popular in scrum poker because the gap between them increases over time (reminiscent of pyramid levels). There are tasks that will have enormous complexity, and a small number of story points cannot be achieved. Explanation for unusual cards:

unknown number of endpoints

an infinitely long task

need a break

More rare methods of estimation:

• in T-shirt sizes - S, M, L, XL
• or in dogs - chihuahua, pug, dachshund, bulldog, and so on (in my opinion, this is the strangest unit for evaluating tasks =D)

The team then compares the estimates given to the same problem by different developers, and if they agree, great! If not, it is necessary to discuss the reasons for the differences in assessment (arguments). After this, we can jointly come to a single estimate, with which everyone, plus or minus, will agree. Well, why is poker even used to plan a serious software project? After all, this is somehow strange. In fact, such gamification encourages team members to think independently, asking them to show their results at the same time as their teammates. This, in turn, avoids dependence on the views of other team members. Otherwise, less experienced developers will look and rely on the assessments of more experienced team members, which will negate the usefulness of their own assessment. But with the simultaneous opening of the results, this is essentially impossible. An example of a Scrum Poker scheduling app is from Atlassian .

Example of task assessment

Let's imagine that your team has identified a certain scale for evaluation in story points: Scrum Poker starts on a task, and you evaluate it like this:

• you have never worked with the implementation of similar functionality before - +3
• functionality of a medium-sized task - +2
• implementation of the task has high complexity - +3
• high complexity of writing tests for this functionality - +3

As a result, you get 11 story points, but since there is no such card, you offer 13. Another colleague of yours evaluates the task:

• worked with a similar problem before - +1
• functionality of a medium-sized task - +2
• the implementation of the task has average complexity - +2
• average complexity of writing tests for this functionality - +2

As a result, he gets 7 story points, but there is no such thing in the Fibonacci numbers, and he places a card with the closest possible number - 8. Other team members, accordingly, give estimates based on their subjective views. Next, you show your results and discover that almost all of your colleagues gave the estimate 13, except for one developer who gave it 8. In this case, he is given the floor and he gives reasons. And they, for example, are like this: he worked previously with the same problem, and it is not as difficult as it might seem, and in the end he convinces the rest of the team members to change their solution from 13 to 8 story points, saying that he will help whoever takes on this task will figure it out. Or, in the end, he will do it himself. And in general, it doesn’t matter whether others listen to his arguments or not, because one way or another, a rating will be assigned to this task, and the team will move on to familiarize themselves with the next one. The first times, estimates will be inaccurate, as will the estimates of the amount of work that you plan to do over the next period of time (sprint). After all, these estimates are made precisely based on estimates. After some time, about three months, the team will begin to more accurately estimate tasks, and the average amount of work that the team can complete per sprint will become visible. But this is general planning of the scope of work, it is more about time, and in this case there may be many different factors that have an impact. For example, one of the developers went on vacation for two weeks. That is, you need to cross out a certain amount of planned work (planned functionality). Or a new developer has come to the team, but you don’t need to fully count on him, because... you need to take into account the time required to adapt to the project, called onboarding . This could be two weeks, plus or minus a week, depending on the complexity of the project. That's all for today, I hope I have slightly improved your knowledge in such a non-technical part of knowledge as problem estimation. If you want to go deeper into this topic, as well as into the details of Scrum, I strongly advise you to read the book “SCRUM” by Jeff Sutherland. I can’t vouch for the consequences, because perhaps after it you will have an annoying desire to become a Scrum Master =D