Agile estimation made easy: how to estimate software development projects

Developing software is a tricky business. Did you know that 66% of all enterprise software projects experience cost and effort overruns? All of that comes down to how we build software today; following the agile methodology requires expertise in agile estimation that presents some challenges software developers.

Factors such as lack of project scope, missing functionalities, or scope changes after project start impact estimations negatively, causing projects to overrun. Solution? The right agile estimation strategy.

Being able to accurately estimate the time required to develop a specific feature or product is a critical skill for development teams. Projects start with rough time estimations and are segmented into particular milestones they need to reach within the designated deliverable date. Developers also make estimates when they break up large tasks into smaller ones they can complete in shorter time intervals. An issue in any of these estimations can impact the schedule of the entire project.

Most of the time, project managers and software developers rely on their intuition which in some cases might be less than accurate. Still, being aware of estimation challenges and knowing tactics to avoid them helps to make the estimation process more accurate.

Here are 10 strategies that help development teams make better estimations.

1. Define the project’s goal

Development teams need to know what the project’s objectives are and how they address the company’s business goals. They also require information about the commitments of particular features or systems as they might need to be ready by a specific date.

Project goals and commitments help developers to check whether the business objectives of the project are realistic enough to allow achieving scheduled commitments within the set time frame.

2. Establish the project’s scope

To determine the work that needs to be put into the project, developers need to know what the application is about.  How to define the project’s scope? Create the functional breakdown of the project in line with the commercial needs of the company and the set commitments.

You can do that by:

• Scheduling meetings with the client to get more information,
• Researching similar systems to serve as your reference,
• Understanding the type of project at hand and industry,
• Validating and prioritizing the functional requirements of the project.

3. Remember about non-functional requirements

Functional requirements describe what the application does. Non-functional requirements say how it works – for example, its performance, scalability, or usability.

It’s important to take these non-functional requirements into account when creating project estimations. Depending on the type of project and industry, non-functional requirements may carry a different weigh. Implementing them may be more or less complicated as well.

4. Prioritize tasks and features

The project estimations and restrictions regarding budget and time frame often make it challenging for teams to achieve the set commitments and deliver the work on time. That’s why it’s vital to prioritize tasks already at the point of agile estimation.

Consider the essential functional priorities of your project to make sure developers focus on them first. In the worst-case scenario, you can postpone the least critical tasks to another project phase.

5. Pick the right agile estimation strategy

You can choose between several approaches for estimating your project, depending on its type, complexity, number of requirements, and delivery times.

Here are the most common estimation strategies for software development projects:

• Traditional estimation – when following this variant, you basically choose a project requirement and assign it a time value according to its complexity and your experience in developing that type of requirements. For more accurate estimation, it’s common to divide a requirement into components (like presentation, business, database) and define the time required to complete each of them. Sum them all up and you’ll get the entire requirement estimation.
• By order of complexity – in this approach, you first assign an order of complexity to all the requirements that need to be estimated and then estimate a representative sample using the traditional strategy above. You then extrapolate the value of your estimations from the requirements waiting to be estimated, according to the order of complexity. This option is a good pick if you’re dealing with a large number of requirements.
• Analogy – the idea here is using your experience in software development and the times achieved in previous projects to serve as your indicators for estimating a future project. For this method to work, you need to have a lot of experience, keep close track of times in your projects, and maintain a knowledge repository for identifying similar projects easily.
• Team – this approach to estimation relies on distributing the requirements by components, system modules, or other criteria which are then passed to specialized groups of estimators. Every group is responsible for estimating the set of requirements assigned to it.

6. Identify project assumptions that might impact estimation

Record all the project assumptions that may influence the estimation and the planning of the project. That way, the person in charge of evaluating the estimation will have all the information required to assess it. This is the best strategy for avoiding the risks of misunderstanding by ambiguous or lacking information.

7. Use estimation tools

Development teams take advantage of estimation tools that help to automate the process and make agile estimation more accurate. Such tools also help to maintain a history of estimations to which the team has access every time they’re asked to create a new estimation. Another benefit of agile estimation tools is that they help to make the group tasks easier and provide teams with rich reports about their estimation efforts.

8. Story points vs. hours

Traditional software teams estimate projects using a time format: days, weeks, months. But agile teams often use story points which rate the relative effort of work in a Fibonacci-like format: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100.

That might look complex, but the level of abstraction involved in story points actually helps teams to make tough decisions about the difficulty of their work. Also, story points allow counting in the non-project related work (emails, meetings, and interviews). Once the team agrees on the relative effort of each story point, assigning points is a quick and effortless process.

Note that completed story points reward team members for solving problems based on their difficulty, not the time spent on the task. That helps the team to focus on delivering value, not just spending time on the project.

9. Planning Poker

Agile development teams that use story points often participate in an exercise called the planning poker. During the planning poker, the team takes an item from the backlog, discusses it briefly, and then each member is asked to formulate an estimate. Then everyone holds up a card with their estimate. This exercise helps to understand the reasons behind different estimates and come up with a more accurate final estimation.

10. Take advantage of your previous experience

If a development team has worked with a specific technology in the past, the developers will be more aware of the potential complications and issues that may crop up during the process. This knowledge plays a crucial role in agile estimation.

On the other hand, developers are always on the lookout for new challenges and optimizations they have little experience in. In such cases, using past experiences as an indication might become misleading and counter-productive.

Agile estimation is easier than it looks

Agile estimation is a complex but essential part of every agile development project.  By following these battle-tested tactics, development teams and companies can create estimations that help to build amazing products, rather than introduce new risks to projects.

More from Concise:
The Beginners’ Guide to Agile Project Management Methodology
Agile way of working, the Concise Way
Agile Without Scrum – Is It Possible?