Software development is, in essence, an industrial process like any other. But an immature one, not only because of the industry’s young age, but also because of the product’s inherent complexity. Software is intangible, physically unbounded (virtually) and in continuous evolution. This makes defining what the product must accomplish — the so called requirements engineering — a task as difficult or arguably even more complicated than building the product itself. Software development is, therefore, an ad-hoc creative process that struggles to incorporate common features from other industrial processes, such as task automation or reutilization, out of the box.
These characteristics make software project management a specially challenging duty, and explain the failure of traditional models, such as waterfall development, that are common in other business areas. Several approaches to software project management have been proposed to address this challenge, with emphasis on the widely adopted iterative processes. Agile methodologies are a set of development and process management practices that fit in this class and promise sustainable, flexible development processes, with fast return on value and high quality results. Even further, agile methodologies are a novel approach to deal with uncertainty and, as so, do not exclude planning, but rather rethink it.
Why do we estimate? And what exactly?
Traditional management frameworks — iterative or not — rely firmly on estimation techniques to assess project features, such as cost and duration, and plan accordingly. However, the generation of statistically accurate estimates is a costly task for the sake of planning. Agile methodologies, on the other hand, are averse to anticipation, tend to lighten the management burden and avoid incorporating activities without short-term value return. Therefore, a critical view over estimation is necessary and should turn up naturally.
While planning a project, the size of the workload and the amount of effort required to do it are probably the most valuable management metrics that one would like to estimate. The idea of size is related to the project’s scope, and the concept of effort could be conceived as an adjusted size, taking into account the development team’s expertise. Other estimates important to clients, such as cost and duration, can be calculated from the estimated effort or size. The essential difference between these metrics is their objectiveness: while the size is clearly visible in the final product — as function points, number of features or lines of code; the effort includes research and other support tasks necessary to complete the work.
As the team-dependent component of effort must be included in the planning, size and effort are often used interchangeably. This is valid, as long as the relationship between them is bound to the team as a whole and not to an individual developer’s productivity. The reason behind this is that a compromise must be made between the team members so the effort necessary to build a specific product varies among teams, instead of individuals. Otherwise, it wouldn’t be possible to elaborate sensible team-wide plans.
How do we estimate?
The common procedure to estimating a project’s workload is through a divide and conquer strategy. The workload is divided into smaller work units whose size is easier to estimate. In agile projects, these sizable units are often called user stories, and the actual metric is the effort required to complete the functionality described in the story according to a definition of done agreed by the team members. The measure of size can be quantitative — numerical — or qualitative — categorical. Examples of quantitative measures are expected time and story points.
Expected time is usually measured in ideal periods — like hours or days of full and uninterrupted productivity. Effort estimation through expected time is often unadvised, as it establishes an absolute size reference (one ideal period) that is subjective by definition. To achieve an estimate understandable throughout the team, every developer must agree on what is the meaning of the ideal period: what is full productivity? How does research and support tasks are included in this definition? Also, this kind of estimate might be seen as a deadline, pressuring developers with less expertise and relaxing those who could actually have the work done faster.
Story points, spread mainly by the Scrum framework, are a common measure when the work units are defined as user stories. The effort is measured with an integer of a predefined sequence, usually the Fibonacci succession (1, 2, 3, 5, 8, 13, …). The size of the smallest story is set to 1, and the other stories are sized relatively. For instance, a story of size 3 is expected to take three times more the effort required to finish the smallest one. This kind of affirmation gets less accurate as the size increases, so large story points are unadvised and indicate that the story can be broken down into smaller pieces. A common method to estimate story points for a user story is the Planning Poker.
Teams and managers can take advantage of quantitative effort measures, as other support metrics can be calculated from them. Some examples are the team’s capacity, the maximum effort achievable in a fixed amount of time; and the team’s velocity, the accomplished effort trend in the near past, which is expected to continue in the near future. Also, once a story is assigned to a developer, it might be easier to predict the time necessary to finish it according to their expertise — which is useful for daily team planning.
However, there are some downsides to using this kind of measure. Numerical estimates can be understood as a commitment of effort to be accomplished and to evaluate the team’s productivity. In fact, estimation techniques used in agile are informal and tend to be overoptimistic, which makes them prone to be inaccurate and lose relevance over time. Thus, evaluating a team according to the estimates generates pressures on the developers and leads to defensive effort overestimation, in order to indirectly lower the management’s expectations.
In contrast, qualitative measures eliminate the risk of being used to set expectations on the development team. A common example is the “T-Shirt Size” method, which uses classic t-shirt sizes — XS, S, M, L, XL — to measure the size of a user story. The sizing is also relative, so a reference user story must be chosen to determine the other stories’ size by comparison.
And if we don’t estimate at all?
Some recent approaches to agile project management propose not to estimate at all. This is a consequence of the high costs of estimation, in conjunction to the biases and uncertainties inherent to software development. Supporters of the #NoEstimates movement argue that avoiding estimation allows teams to deliver more value, faster and consistently, while avoiding the common misinterpretations these artifacts have. Although there are testimonials about successful projects that purposefully don’t use estimates, the question about the feasibility of this approach in bigger projects remains unclear, as good estimates are helpful for planning in complex scenarios and are frequently a requirement from clients.
This change of paradigm has awakened the debate about the purpose of estimation in agile projects, when it is valuable and how to optimize this process. Opinions of professionals and academics seem to converge to a common point: management and development teams should be encouraged to review the objectives of estimates in their projects, how they should be interpreted in each context and make sure that they are used to support project planning and management, rather than team evaluation.