Effort Estimation in Agile Projects

In software engineering, testing is one of the most crucial aspects as far as software development goes.

That’s because testing assures the perfect functionality of a product and guarantees customer satisfaction as well. Therefore, testing needs to be handled with the uttermost care, which means that proper planning and effort estimation must be executed properly.

Associate QA Lead

Testimonial Author

Aloka Gunathilake

An estimation is a rough calculation of quantitative features, and it enhances the productivity of a process. Likewise, in software development the estimation plays a vital role. Test estimation is also a critical task in sense of accuracy of product. It makes an attempt to predict the timeframe for software testing. Same is put to use for finance and other resource allocation.

Test estimations have evolved over the years. At present, the project teams have deployed different methods to produce the estimations. In traditional methods, the estimation is calculated as 30% of the development effort. According to the level of experience in the particular module, the estimations are given with good confidence.

When a test estimation is issued, key factors such as the scope, risks, test case preparation and type of testing needed to perform are taken into account. However, this methods is not versatile enough to reach the most accurate estimation. For example, an instance where development is insignificant, but its impact on other functions may be substantial. In this occasion testers’ work is prolonged.

Therefore, the 30% of development effort rule does not estimate an accurate timeframe.

Other than the above method, there are versatile tools to obtain test estimations. A project in which I was engaged in, opted to follow the Agile development method. Therefore, testing tasks had to be align with Agile.

In this development method, the testers encountered several challenges. Being part of a team towards one objective, providing leadership for corporation of the team, mitigating risk in limited documentation and preparation of test estimation are a few challenges to mention.

Two techniques were proposed to prepare the test estimation.

First one was story point; in this method the difficulty level of the story is given by numbers. Requirement complexity, risk involved and the effort to be made are the deciding factors of difficulty level. Story point implementation is comprised of the efforts of both the developer and QA. If further testing efforts are predicted, QA needs to emphasize it. Story point allows to plan the sprint and provides guidelines on whether it can be completed during the timeframe. The most popular way is to identify by 1, 2, 4, 8, 16 points. Fibonacci series (1, 2, 3, 5, 8) is also used.

Second one was the hour based estimation. This involves in preparing the estimation based on man-hours which are required to complete the user story. In this method also, man-hour estimation will depend on requirement complexity, risks involved and the effort to be made.

Further, the time spent on the project needs to be recorded accurately since the customer plans to pay on hourly basis. This means that the project needs the tools, which enable to enter the time it took to complete for a particular task.

After comparison of story point and hour based estimation it was decided to select hourly based estimation. The project was completed by using Jira, which facilitates to maintain estimate actual and remaining time.

According to observations from the above project and others, it is empirical to share the value of estimation across the team. The test estimation has multiple impact on the project. It enhances the customer confidence on quality and punctuality of the project. Further, the same is important to make technical and management decisions. The ultimate goal of test estimation is to present a pragmatic timetable for a project at minimum cost. This is an indispensable requirement for every project since the customer expects the best at minimum cost and timeframe!

Get in touch