ESTIMATIONS IN SOFTWARE DEVELOPMENT: A BRIEF INTRODUCTION

Photo by Austin Distel on Unsplash

Disclaimer: In this post, I have tried to follow an empirical approach (in line with what Scrum prescribes), based mainly on my experience as a Scrum Master in software development teams. Although it may include some theoretical insights, it is not my intention to provide a detailed analysis of what is covered in specific literature on the subject.

One of the concepts traditionally associated with the Agile approach in software development, particularly with Scrum, is estimation. While the Agile Manifesto does not explicitly mention estimation, we can consider that its principles implicitly recognize the need for predictability (delivering working software frequently, at a constant pace) and the ability to manage value deliveries in a more adaptive manner (welcoming changing requirements). Both points, which may seem contradictory at first glance, are indeed complementary. We are not talking about fixed delivery dates that are constantly postponed, as often happens in more traditional approaches. Instead, we are talking about the need to maintain realistic expectations while keeping in mind the adaptability required in the inherently complex software development environment.

However, throughout my career, I have had the opportunity to work with clients who boasted about being very agile because they used estimation, and the team itself carried it out. There’s nothing more Agile than that, right? Nevertheless, we need to be very careful with this approach because estimation precisely means ESTIMATE. One of the definitions that the dictionary provides for the word ESTIMATE, regarding measurement, is literally GUESS, which in turn means “estimate without knowledge”. This is the key here: the level of uncertainty is so high at this point that what we are doing is simply relying on our intuition and previous experience to make a high-level guess about how much effort a task might take.

I’m not going to delve into using story points as an estimation measure, as it’s a topic that is substantial enough to be addressed in another post. Allow me just a small spoiler: based on my experience, story points are NEVER used as a measure of effort. They are frequently used (even unconsciously) as a measure of the time that someone will take to do something.

BENEFITS OF ESTIMATION

Now that this is clarified, let’s consider some of the reasons why estimations can be a useful tool when used appropriately:

1. Predictability and planning: Estimations allow a clearer understanding of the effort required to complete a task (note: when I say “task” I mean a portion of work, not a Jira item). This might help to create high-level roadmaps with time references and to plan sprints and iterations more effectively. The resulting predictability helps teams and organizations make informed decisions and manage stakeholder expectations (“managing expectations” is one of my mantras).
2. Adaptability and transparency: Here, adaptability refers to flexibility in managing priorities. Estimations provide an idea of the effort required to develop different features and functionalities of the product. Even if it is based on non-scientific data, it helps in deciding which functionalities should be prioritized and which ones can be addressed in future iterations. Estimations also promote transparency by sharing information about project progress and limitations.
3. Collaboration and communication: For me, it is the key and the true differentiating value of this concept. We could argue whether the estimation process helps us to achieve greater predictability or adaptability, but what is undeniable is that it promotes internal dialogue and knowledge sharing, assuming that those conversations take place in a safe environment where people can freely express themselves without being influenced by the group’s opinion. Estimation in Agile fosters dialogue and collaboration among team members. By involving all team members in the estimation process, we leverage different perspectives and knowledge, leading to more accurate estimations and a shared understanding of tasks and risks. Estimation also facilitates communication with stakeholders, especially those without a technical background, as it allows them to anticipate the difficulties the team foresees in undertaking a development. Even though it may be a rough estimation (not detailed, unpolished) with a low level of accuracy, it is better than nothing when it comes to managing their expectations.
4. Continuous improvement: Estimation in Agile is not a static process but evolves over time as the team gains experience and adheres to the principles of inspection and adaptation. Through reviewing and analyzing previous estimations, teams can learn and improve their ability to estimate more accurately in the future. This leads to increased efficiency and productivity as the team develops a deeper understanding of their own performance and limitations.

TECHNIQUES OF ESTIMATION

Now that we have seen the value that estimation can bring us, let’s look at some of the most common estimation techniques in development teams.

- Planning Poker: is by far the best-known, mainly thanks to its use in teams working under frameworks like Scrum. It is based on a deck of cards, where each card represents a numerical value (usually using the Fibonacci sequence that increases the distance between values, thus representing the exponential growth of uncertainty as we consider the task to be “larger”). The value of the cards is typically associated with the concept of Story Points.

- T-Shirt sizes: if we want to have a more holistic picture and be able to classify work items into “sizes,” we can use this technique, which involves assigning a T-shirt size (XS, S, M, L, XL) to each item in the backlog. This allows us to make faster progress in our estimation, especially if we have multiple stories and want to classify them at a high level to help us prioritize and then break them down in more detail as the time to work on their approaches.

- Bucket System: more than an estimation technique, this is a way of classifying backlog items. It consists of creating a list with all the backlog items and placing them in columns (physical or virtual), assigning a value to each one (either in story points, T-shirt sizes, or any other appropriate measure). We start with a well-detailed first story that everyone clearly understands and try to reach a consensus on where to place it. From there, the team is free to take the cards and move them wherever they think they fit best, using the initially placed item as a reference. This system encourages discussions and sharing a common understanding of the scope of each task and the potential challenges we may face in resolving it.

There is also a movement that advocates for completely avoiding estimations (#noestimates). Supporters of this practice argue that the time saved by not estimating outweighs the supposed benefits of estimation, which we mentioned at the beginning of this article. In my opinion, for this to be the case, we should start from two premises that are as clear as they are difficult to achieve: first, the team in question should have a high level of agile experience and maturity, and second, as a direct consequence of the first, they should be able to divide the work into backlog items of similar size, with the complexity that entails in achieving elements that meet the INVEST criteria that govern the division of a backlog item.

Here is Jeff Sutherland’s opinion, one of the creators of Scrum, on estimations:

To finish, I’d like to throw a question for us to reflect on the purpose of estimations in our teams: Why do we estimate? What exact value does it bring us?

If the answer is related to promoting dialogue and trying to create a shared understanding of the complexity of a task, then continue doing so, as you are likely harnessing the value it can provide.

However, if the answer is more focused on setting deadlines, clearing stakeholders’ uncertainty, or creating a rigid scale of development timelines based on task types, estimations may be generating more problems than value for you… Tools are just tools, and as Agilists we really do value Individuals and Interactions over Processes and Tools (as stated in the Agile Manifesto).

To get the real value that the estimations can provide, we must use them appropriately, so if you decide to use estimates in your team, make sure you do it wisely 😉

PS: Special thanks to Greg Lucy for encouraging me to write this article, and also to Laura Heaney for her suggestions.

About the Author:
Carlos Sampedro is a Scrum Master here at Version 1.