Many articles and books have been written on the fact that estimates of tasks in story points contain less margin for error and allow for more accurate forecasting of project timing by the current development team. But what to do if the team is very small, or the customer's priorities change too often, if the tasks vary greatly in volume and complexity of implementation, and contain a high degree of uncertainty? Can estimating tasks in hours provide planning advantages in some situations? We say yes, it can, and in this article, we will tell you when, why, and how we do it in one of our projects.
Without disclaiming responsibility for the quality of estimates in project сompletion, we want to reveal the non-obvious problems that estimate also solve (besides the main one - predicting deadlines) and to illustrate how and for what purposes you can use estimates in hours.
Story points method: pros and cons
The story-points method is one way to evaluate software development tasks. It is a conditional value that allows you to assign relative weights to the backlog elements, which correspond to the labor intensity of the tasks relative to each other.
There's no point in retelling articles and books about the benefits of story points grades. This method has several advantages and unique features:
- Tasks are compared to each other. The evaluation in Story Points is relative.
- It takes into account possible risks and uncertainties in the requirements.
- The whole team takes part (not just the tech lead or PM). Estimation is objective and doesn't depend on a particular task performer.
- Based on story points, the estimate of the release date is corrected, taking into account the average “speed” of story points digestion by the development team. The adjustment is relatively simple - all tasks are evaluated relative to each other. If the team's average velocity changes (the number of Story Points a team closes during one sprint), just divide the total project estimate by the new velocity value, and you'll get new project deadlines.
It sounds cool, and there are many advantages but don't get too excited. Generally speaking, the model is difficult enough to use. In order to successfully use story points, certain conditions must be met.
How to use the story points method effectively
Firstly, the project must be long enough. The first few sprints will take to understand the average team and make a more or less accurate estimate of the entire project's duration and individual features.
Secondly, the team composition should be stable over a long period of time. When a developer leaves, velocity obviously drops—but we don't know by how much—and when a new one comes to replace him or her (most likely not immediately, but after some time), he or she needs some time for onboarding. Then the newcomer's grades introduce error, and the team's velocity also changes unpredictably.
Thirdly, the team should consist of more than 2-3 people. If you have two developers, you will not get any advantages in this assessment.
Fourthly, the level of expertise must be quite high. We mean middle and senior developers. All the matter is that it's hard for junior developers without experience in a project and knowledge of the code base to give any estimates for features or tasks, mostly formulated abstractly at the initial stage. A team consisting of a team leader and junior developer will not be able to use story points at all.
Lastly, the project's scoping is stable and can be seen several months ahead. Priorities for feature development are also stable. If not, you'll have difficulties with relatively “long sprints” (3–4 weeks), and the overhead of planning and evaluating routines may exceed the benefits of accurate evaluations.
In addition, there are nuances. Within the adherents of the methodology, there is an ongoing debate about whether it is necessary to evaluate bugs that will take the time or whether only new functionality that adds value should be evaluated. The second approach reduces the risk of formal “closure” of the task (just to do, bugs can be fixed later separately).
It is not quite clear what to do with the estimates of the tasks that the team did not have time to do during the sprint. Should they be corrected in the new one or not? If so, how? If not, how to estimate average velocity, for example, for this pair of sprints?
Let's add here the requirement for the overall maturity of the team. The evaluation process in story points is generally more difficult to understand and work with (in planning poker, you need to evaluate abstract tasks, give an opinion, and argue for it). Not all teams are mature enough to understand the concept and benefits of story points. Requirements for cooperation increase because tasks, like evaluations, are now common to the whole team — success or failure in completing a sprint depends on the overall efforts of the team as a whole, not personal efforts. Rituals become longer, and planning poker involves discussion, reasoned argument, etc. Overall, this approach has both pros and cons. But, the world experience says that the disadvantages in assessing tasks in the clock still prevail.
Estimation in hours: pros and cons
Task estimation in man-hours (or simply in hours) is a way to estimate the labor intensity of a task. Here and below, by estimation in hours, we mean the total amount of time it takes for the developer to implement the required functionality, write tests (if required), passcode reviews, correct remarks, and fulfill other requirements of the DoD (Definition of Done). QA time for testing is counted in a separate task.
In some cases, the complexity of evaluating tasks in story points may make it impossible or impractical to use them. What to do, then? We suggest taking a simpler tool and, understanding its limitations, trying to increase its accuracy. Earlier, we talked about task estimation in a one-sided way—as a way to find out the deadline for project completion. In fact, task estimation has several purposes:
- Allows you to estimate the timeframe for the сompletion of an entire project or major features.
- Sets goals for the sprint for each developer and allows you to track progress.
- Allows you to schedule the work for the sprint.
- Lets you distribute the workload within the team.
- Defines metrics.
- Allows you to review the sprint and draw conclusions.
Let's say right away that perhaps the main task of estimating in hours does not solve it well enough. Estimates of the entire project are inaccurate. However, it is useful under certain conditions for structuring the team's work process.
Estimating the labor intensity of tasks in hours is familiar and intuitive. It does not need to be explained to novice developers and can be used immediately without long preludes and slippage. This assessment will be easier to use in a team that is just starting to work together and people are not yet accustomed to each other. It can take up to six months to get used to the adjustment.
It is unfortunate if your project is constantly changing composition, but it happens. Estimates in hours, if used correctly, will make fewer errors than estimates in story points, as they will automatically take into account the withdrawal of developers. The new participant will break terms only for their tasks, under the condition that others have learned to work with estimates in hours. The accuracy of estimates of the rest of the team will not change, so the impact on estimates will be less.
If stakeholders or product owners prefer to control how the project is going, estimates in hours are more understandable for them. Then the team has less time to explain and agree on priorities and implementation, and the situation becomes more transparent for the stakeholder. In this case, there is practically no need for reporting; the stakeholder just needs to study the events in Jira.
Hourly estimates can be used with any grade and number of developers. Besides, estimating in hours is more profitable in short sprints of 1-2 weeks. After all, there is no need to use planning poker. Grooming tasks can be done asynchronously, while the planning rally itself does not take much more than standups (30-60 minutes). In turn, the need to use short sprints can be caused by a high level of uncertainty in the project and frequent changes in priorities. In this case, we do not waste time working through those tasks that may later be canceled or postponed.
Finally, in short projects of 2-3 months, estimating in hours will allow you to faster and more accurately define the timing of the project before it begins. If we're going to estimate tasks in story points at the beginning, we won't know how many of them the team will be able to close in one sprint, so after doing 1-2 iterations, the estimate will have to be adjusted. This way, we will get something more or less accurate only by the end of the project.
How our team works with task evaluations
Now, let's move on to practice and discuss how exactly we use task estimation in hours at Mad Devs, with one of our projects as an example.
The team consists of 4 Backend developers ( two junior developers, a middle developer, and a tech lead), a frontend middle developer, a QA engineer, and a PM. The length of the sprint is one week. The project involves frequent changes in priorities due to external factors associated with the legislation requirements in the customer's country.
The project, despite being in production, has a very high level of uncertainty. Pivots occur on average once every two months. Urgent burning tasks can appear every week. There have been cases where the design and development we did in 1.5 months had to be stopped and code was thrown out. To predict the completion of a project or major milestones, we use estimates of large blocks of functionality that were made during design. They are made with a reserve and are substantially revised further when planning sprints.
Planning cycle and evaluating tasks in the project
For short sprints, around one week, we have to plan weekly — usually on Fridays. We start preparing for the planning sync on Monday to use the team's time efficiently. A PM assigns the tasks for developers in the next sprint, while a tech lead asynchronously looks at the distribution and adjusts if necessary. When planning, we immediately assign tasks to performers, and labor estimates are set by the tech lead.
When we work with the backlog, we don't just plan the next sprint. We also schedule tasks for the next ones, depending on whether they need to be implemented in a certain sequence. So, we have 2-3 sprints prepared all the time. The further away the sprint is from the current date, the lower the accuracy of the estimates and the list of tasks in them. This draft allows us to spend less time when planning future sprints.
We don't fully plan for 100% of the guys' time. Typically, a developer’s total net time estimate is 2.5 to 3.5 work person-days out of five. We subtract from the workweek the time we will definitely spend on retrospectives, timelines, team code reviews, and communications. For junior developers, we plan for a smaller workload, meaning that a significant portion of the time will be spent on troubleshooting comments.
When the sprint is scheduled and approved by the tech lead, each developer reviews the tasks, asks questions, gets to know the code if necessary, and pre-decomposes and evaluates tasks before the planning meeting. That is what most of the sprint looks like. During this time, the developers to whom the tasks have been assigned learn the requirements, refine them, and make the decomposition. The more granular the decomposition, the more accurate the final estimate of the task will be. So the initial estimates are refined and changed, but based on the research done, considering the strength of those who will implement the task.
Then, a planning meeting comes up. We discuss and adjust the total task estimates in the sprint so that the scope is feasible for every teammate. Starting the following Monday, the developers take the tasks from the sprint and work on them. On Friday, before the planning meeting, we review the sprint and discuss how accurate the estimates were, what went wrong, and how to avoid problems in the future.
Wrapping up
In our experience, we tried to be honest about all the pros and cons of working with task assessments in hours. It is only one of the tools that can be useful if you know how to apply it.
We use hours when planning short-range work, such as one or two sprints. Such estimates allow us to make short-term planning predictable and qualitatively analyze outcomes.
A prerequisite for accurate estimation is low granularity decomposition. You can achieve more or less accurate estimates if you break tasks into smaller ones with a labor intensity of 2-3 hours.
Task estimates within a sprint serve as a pretty good motivator. Developers strive to achieve the goal and close all tasks within the sprint, so it stimulates a personal responsibility for the task.
We get something else as a bonus. With the described approach, the estimate differs from the actual time of task completion. Usually, there are only two reasons for that. Firstly, if the developer doesn't t spend enough time studying the context and specifying the requirements when planning the job. Secondly, deviations from estimates during decomposition clearly show how well a particular developer decomposes a task. The higher the deviation from the estimates, the more attention should be paid to skills growth.
In addition, it clearly shows the team the benefits of decomposition, which is not always obvious to everyone. In any case, at the sprint review, the practice helps PMs analyze and work on solving common problems.
