Meet your deadlines: methods that developers use to estimate effort

Hello, everyone! There is a colossal amount of theory that you need to know to get started in software development. Some specialists (for example, backend developers that use Java and other languages) know more of it, while others (for example, frontend developers that use JavaScript and React Native) may know a little less. That said, both groups must possess a large body of not only technical, but also "organizational" knowledge. This "organizational" knowledge is one area of overlap for frontend and backend developers. Today I want to talk about an aspect of this non-technical, organizational knowledge. Today we will talk about effort estimation. Because I only have experience using the Agile methodology (which is considered the most popular), more specifically the Scrum framework, I will consider effort estimation in the context of Scrum. Right at the outset, I must say that effort estimation is difficult. For me, it is one of the most challenging/unpleasant aspects of my job as a developer. There are many different factors to consider that can affect your estimate of the effort required for a task. Additionally, future development plans will be based on your estimates.

What if you provide a bad estimate?

If a developer estimates far more hours for a task than are eventually spent on the task, their expertise may be put into doubt since the estimate was so inaccurate. In other words, it was a wild guess. At the same time, if a developer doesn't get the work done in the predicted time, she jeopardizes the customer's plans to release the product or new feature. This is business, and business is money. Few customers will be pleased with such a slip. In fact, that's why I don't like estimation — because sometimes it is super tricky to accurately determine the time required to complete a task.

How to make a time estimate

As a rule, estimates are made in hours or story points. My personal preference is to do the estimation process using story points. It's hard to be mistaken about concrete physical objects, but story points are a little more abstract. Software development teams typically provide estimates as amounts of time: hours, days, weeks, months. These time estimates are based primarily on personal experience, guesswork, and/or intuition. In this case, developers simply look at the task and express their assumption about how much time it will take them. As a result, these estimates are very rarely accurate, because there are too many factors that can affect the duration of the work. That's why many teams that use the Agile methodology also use story points. Let's dive in!

What are story points?

A story point is a unit of measurement for expressing an estimate of the total effort required to implement a certain piece of functionality fully. That is, we're talking about relative complexity. Teams assign an estimate in story points based on the complexity of the work, the volume of work, and risk or uncertainty. These values are usually assigned to more efficiently divide the work into smaller pieces, thereby eliminating ambiguity. Over time, this helps teams understand what they can accomplish in a given period of time and helps them more accurately plan subsequent chunks of work. This may sound completely counterintuitive to you, but this abstraction is indeed handy: it pushes the team to make tough decisions about the complexity of the work. Let's take a look at some of the reasons to use story points when planning:

• You can avoid inaccurate time estimates.
• Unlike estimates made in units of time, story points let you account for overhead costs: communications between team members and the customer, various team discussions and planning activities, as well as unforeseen situations.
• Each team will estimate their work using different scales, which means that their capacity (measured in points) will be different.
• By defining a scale for assigning each story point, you can quickly allocate points without much controversy.

How NOT to use story points

Unfortunately, story points are often misused. Story points can be misleading when they are used to assess people, define detailed deadlines and resources, and when they are mistaken for a performance measure. Instead, teams should use them to understand the scope/complexity of each task and to set priorities. Perhaps that the parts that are regarded as more difficult should be tackled first, so they can be done before the end of the sprint, possibly shifting easier tasks to later. Let me remind you what a sprint is in the context of the Scrum methodology:The length of this time period is determined when development begins and is agreed between the team and the customer. This can be a period of two weeks or a month, or any other period. As a rule, the effort estimates are made at the beginning of each sprint in order to plan the work that can be completed by the end of the sprint, when the completed work is delivered to the customer.The demo helps you see your progress in developing the product, receive feedback from the customer, and adjust the project's trajectory according to the customer's vision. But we digress a little. Let's get back to estimates. It would be too subjective to have just one developer provide estimates for all the tasks. So this process is usually a team effort. There are quite a few techniques that teams can use to generate estimates. Today we will look at the most popular technique: scrum poker. This technique requires a manager who will act as a moderator for the scrum poker. This can be someone who is a scrum master or possibly a PM.

What is Scrum poker?

Scrum poker, or planning poker, is an estimation technique that is based on reaching an agreement. It is mainly used to estimate the complexity of the work ahead or the relative size of software development tasks. I'll say straight away that scrum poker is a common software development practice, and you need to know what it's all about. It usually involves an app or website to facilitate a team's collaborative creation of an estimate for a particular task. How does this happen? The team takes something from the backlog (a new task, some functionality) and briefly discusses possible pitfalls and other nuances associated with it. Then each participant chooses a card with a number that reflects their complexity estimate. Oh, one more thing, when making these estimates, we use numbers in the Fibonacci sequence rather than ordinary numbers. Fibonacci numbers are popular in scrum poker, because there is an increasingly large gap between them (resembling the levels of a pyramid). Some tasks will be highly complex, and we won't be able to get away with a small number of story points. There are some unusual cards that have the following meanings:

Unknown number of endpoints

Infinitely long task

Need a break

Less common estimation methods use:

• T-shirt sizes — S, M, L, XL
• Dog breeds — chihuahua, pug, dachshund, bulldog, and so on (personally, I think this is the strangest unit of measure for effort estimation =D)

The team then compares the estimates given by different developers for the same task. If they agree, then great! If not, then the reasons (arguments) for the different estimates need to be discussed. After that, the team works together to form a single estimate that everybody accepts, more or less. So why is poker even used to plan serious software projects? You have to admit that this is strange. The fact is that this kind of gamification encourages team members to think independently, inviting them to reveal their estimates at the same time as their teammates. This, in turn, avoids creating a situation where some team members depend on the opinions of others. If it were not done this way, then less experienced developers would look at and focus on the estimates provided by more experienced team members, and that would make their own estimates less useful. But simultaneously showing the estimates makes this essentially impossible. Atlassian offers an scrum poker app for using in the planning process.

Example of effort estimation

Suppose your team established the following scale for assigning story points to estimates:Scrum poker is played for each task, and you provide an estimate as follows:

• You have never implemented similar functionality before: +3
• The functionality is average-sized: +2
• The implementation will be highly complex: +3
• Writing tests for the functionality will be highly complex: +3

Adding up each component, you get a total of 11 story points, but there is no such card, so you suggest 13. A coworker puts forward the following estimate for the task:

• He has worked with a similar task before: +1
• The functionality is average-sized: +2
• The implementation will be of average complexity: +2
• Writing tests for the functionality will be of average complexity: +2

His intermediate result is 7 story points, but that number doesn't exist in the Fibonacci series, so he submits the card with the most approximate number — 8. Other team members also make their estimates based on their subjective views. Then everyone shows their cards and you find that almost all of your coworkers gave an estimate of 13, except for the one developer who suggested an 8. In this case, he is allowed to speak to gives reasons for his lower estimate. Suppose he offers this justification: he previously worked on the same task, and it is not as difficult as it might seem. Ultimately, he convinces the rest of the team to change their mind from 13 to 8 story points, saying that he will help whoever ends up taking this task. Or perhaps he will do it himself. In any event, it doesn't matter whether the others accept his arguments or not, because one way or another an estimate will be assigned to the task, and the team will move on to consider the next one. Initially, estimates will be inaccurate, as will the estimates of the amount of work that you plan to get done in the next period of time (sprint). After all, these estimates made using estimates. After some time, maybe three months later, the team will begin to estimate the time required for tasks more accurately, and the average amount of work that the team is capable of performing in a sprint will become apparent. But this is a process to make a general plan for the scope of work. It focuses mainly on time, but in this case there may be many different relevant factors. For example, suppose a developer went on vacation for two weeks. You will need to cut a certain amount of planned work (planned functionality). Or suppose a new developer has joined the team, but is not yet fully up to speed, so you need to allow her time to become familiar with the project through an onboarding process. This could be two weeks, give or take a week, depending on the complexity of the project. That's all for today! I hope I slightly improved your knowledge of effort estimation, a necessary non-technical aspect of software development. If you want to go deeper into this topic, and into the details of scrum, I strongly recommend that you read the book "SCRUM" by Jeff Sutherland. I can't make any promises about the consequences, because after reading it you will have an annoying desire to become a scrum master =D