{{announcement.body}}
{{announcement.title}}

Agile Estimation — Prerequisites for Better Estimates

DZone 's Guide to

Agile Estimation — Prerequisites for Better Estimates

You can pick up any type of agile estimation technique, but it will go wrong if you don’t have the prerequisites for the estimation process.

· Agile Zone ·
Free Resource

measuring tape

Find out how to improve your Agile estimation skills!

Estimation is one of the important phases of software development. Getting it wrong will be a big risk for other activities. You will get plenty of content on the internet to understand the different types of estimations in agile. Some of them are like a poker game, t-shirt sizing, dot voting, affinity mapping, etc. You pick any type of estimation technique, it will go wrong if you don’t have the prerequisites for the estimation process.

I will be discussing those important prerequisites for doing the right estimation in my article.

You may also like: Agile Estimation: What Worked for Us!

Experience and Optimization

There is no right or wrong type of estimation. All estimations are correct based on their understanding of the work. It is also very much personalized. To check this, ask the estimation for the same story from a less experienced developer and very experienced developer, there will be a quite difference in the numbers. It is not because of an individual person. It is mainly because of their understanding of the requirement and the experience of executing similar requirements.

The better experience will help to optimize the process, work, and re-usability factors to have even better estimates.

Holistic Approach and Deeper Analysis

Also, how do you plan to execute it? Someone might consider all aspects of functional requirements, nonfunctional requirements to estimate it as big. Another person might estimate as low without considering nonfunctional requirements like security, performance, etc.

It also depends on your delivery best practices, if you consider Unit Test, Automation, Accessibility, device support are part of doneness criteria then the estimate would be different. Of course, I definitely recommend all these best practices are part of your estimation. These best practices are a must for quality and better maintenance. They will cut down the cost in the long run.

So the point here is about the prerequisites before getting into the estimation process irrespective of the type of estimation technique.

Importance of Retrospective

In my experience of 19+ years of software development, I am very happy and proud to say we have experienced only a few failed cases. The critical thing that we followed is learning from previous experience. It is important to identify the aspect that caused the turbulence in the process and made it fail.

In agile, the retrospective of each sprint in a positive angle is very important. Making mistakes is not a problem but not retrospecting them and finding solutions to those mistakes is a problem. As we do more frequent deliveries in agile, correcting mistakes as early as possible is very crucial.

I strongly recommend doing retrospective after each sprint with a very open mind, identify the improvement areas, and find the solutions for them. Ensure they are into action immediately from the next sprint.

Prerequisites for Correct Estimations

I cannot recommend failing for learning all techniques. Here are the very important prerequisites that have helped me to be more accurate and successful.

Level the Ground

The development team and product management team must be on the same page. The development team must understand the business goals equally with the Product management team.

Also, understand the objectives of the product management team and identify must-have requirements for supporting business growth.

It will help you to decide the type of architecture foundation required. As per business goals, the expectation is going bigger in terms of size (user, data footprint) in the road map then the architecture will have to be different from the shorter business goals.

You cannot do overengineering for the projects that are expected to work for smaller growth and footprint. It means the engineering team must understand the business expectation and be in line with the business team.

Detail the Requirements

Before attempting to estimate, understand the requirement thoroughly. The estimate might differ due to a lack of understanding requirements.

There are many ways of getting the right requirements. One of them is a top-down design. More details can be found in my article.

You need to detail the requirements as much as possible for getting the right estimates. If you are expecting high-level estimates then understand requirements in a broader way instead of deeper.

Understand the complexities of the modules, their integration challenges, and the size of the modules. It will help you to come up with high-level estimates.

Well-Defined Scope

While understanding the requirements and designing the systems, it is important to understand the scope of requirements. Most importantly what is in scope and out of scope.

The level of implementation required for the business. Some of the questions that we need to ask to define the scope are

  • Do we have the scope of developing the product for online or offline or both?
  • Understand the roadmap of the product in the long run. It will decide the life of the product, helps to consider the architecture required for supporting the life of the product.
  • What kind of load the system has to support?
  • Do we need to support mobile users, is it required to have a mobile app or not?
  • In the case of a web application, the level of support required for devices, accessibility, etc.

These kinds of questions clear the gap between the business and engineering teams. It will help you to get closer estimates.

Research Spikes

There are many cases it is not possible to estimate due to a couple of reasons.

  • No exposure to the technology or Domain.
  • Complex requirements.
  • Technology challenges.

Some of them might be roadblocks and cannot estimate without getting sufficient information. In such cases, we must use research spikes. These are time-boxed tasks to understand them better. These research spikes will give enough information on the gray areas.

Balanced Team

The estimation also depends on the right engineering team. The engineering maturity of the team. People must try their best effort for understanding the requirements and also use their experience to foresee the challenges in both requirements and implementation.

The team must be composed of seniors and juniors. It will give different perceptions while doing estimations. It will help to arrive at a good estimation.

On top of all, the team members must be open-minded to ask more questions and get the requirements thoroughly.

Nonfunctional Requirements

Finally, the team must consider nonfunctional requirements like security, performance, scalability requirements, caching, accessibility in each and every requirement. The team must question themselves about these factors for every requirement. It will also play a bigger role in estimation. We must consider them as part of the estimation for any requirement.

On top of adopting specific agile estimation techniques, considering the above perquisites will ensure the estimations are spot on or at least very close to reality.


Further Reading

Estimation Techniques

Stop Estimating: The #NoEstimates Movement in Agile

4 Things I Include in My Agile Estimations

Topics:
agile application delivery ,estimation techniques ,estimating and planning ,sdlc ,best practises ,retrospectives ,non functional requirements

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}