Navigating Uncertainty: Strategies for Enhancing Estimation Accuracy in Agile Project Management | by shiiyan | Apr, 2024

In the realm of software development, a common scenario would be

• When starting a project, engineers are asked to make estimations on how long it will take to complete the project.
• After some time, the team finds out they are behind schedule.
• The developers begin to feel worried and stressed. Some developers may even overwork themselves to prove that their initial estimates were correct.

People tends to be optimistic and think highly of their past success and skills. They recall their achievements easily but sometimes overlook the challenges and struggles they went through.

Pressure from management may also play a role. This comes in two forms:

• Explicit Pressure: Managers may ask the team to finish the project faster or express dissatisfaction with current timelines.
• Implicit Pressure: Without directly saying so, managers might hint that they want faster results and encourage the engineers to make higher exceptions on themselves.

Uncertainty is a deeper reason why estimates often fail. Even without pressure from outside, it’s difficult to predict how things will turn out because no one can see the future. Requirements might change as the project goes on, and sometimes it comes to light that the initial data models does’t meet the updated requirements.

First, we need to understand that making an estimate is making a guess based on what we think we know. The accuracy of estimations, which we call precision, is about how likely it is that the project will finish on time as predicted.

At the beginning of a project, our estimates are just a shot in the dark, with no certainty at all. By the end of the project, after we have done all the work, we know exactly how long it took, so our estimates become 100% accurate. In reality, our estimations in project planning fall somewhere in between but are closer to the beginning when we know less.

When an engineer is requested by a manager to make estimates, it’s important to discuss with the manager the assumptions involved and the precision required. If high precision is necessary, the estimation process will take longer. In most cases, making decisions does not require 100% accurate estimates. Thus, engineers who make estimates should not consider them as commitments.

In reality, in order to adapt to changing circumstances and new information, decision-making process such as project planning needs to be flexible and conditional. In agile development, this flexibility is enabled by an activity known as release planning.

Release planning is an activity that allows a development team to decide when and what to release, ensuring that the team meets the project goals within the established timelines. Usually, the first release planning occurs after the release scope is defined, user stories are clearly outlined, and all stories have been assigned story points. During the release planning, the remaining sprints needed to meet the release goals are calculated using the following equation:

Total points / Current velocity = Remaining sprints

An important point of release planning is that the results are periodically refined. At the beginning of each sprint, the total story points are recalculated to account for any changes. For example, if requirement change, developers may add new user stories to the backlog and assign story points to them, which are then added to the total points. New insights, such as previously overlooked edge cases, may also require adjustments to the total points.

The team’s current velocity is refined every sprint as well. In my previous team, we calculated velocity based on the story points achieved in the most recent sprint, the current sprint and the upcoming sprint. We included the upcoming sprint in our calculations because factors like planned vacations can significantly alter available work time, thus affecting the velocity.

As a result, we managed to make a correct estimation of the release date at the 1/3 mark of the project, which is two months into a six-month project. There are two main reasons for this. First, the requirement were mostly clearly defined after the first two months and remained stable since then. Also by the end of this period, the most challenging technical problems had been addressed. Second, the velocity became stable as developers got used to the new development tools and business domains.

This result aligns with the above explanation of the relationship between precision of estimation and schedule. We didn’t wait for the project to be complete to get 100% accurate estimates. In my case, being one-third into the schedule with 80% precision is more than sufficient to announce the release date of our new features in a press release.

However, I have to clarify that while this practice of repeated release planning improved the precision of our estimates and helped us deal with uncertainty through out the project. it hid not accelerate our development or directly improve our velocity. First, the practice itself takes up to 20% of a sprint. And we have indeed encountered several times when our calculated release date was significantly behind the business goals.

When that situations happen, we need to make decision between flexible scope with fixed schedule and flexible schedule with fixed scope. Kenneth Rubin’s book, ‘Essential Scrum,’ provides a detailed explanation of these concepts. In my last project, sticking to the timeline was crucial because our competitors had already been offering the features we were developing for a year.

Consequently, we made significant changes to our release scope: removing unnecessary user stories, simplifying the ones that can’t be removed, shifting application functionality to manual operations using the admin system. Some engineers began to take shortcuts in their coding, sacrificing code quality to gain more time. Some engineers chose to overwork themselves.

We completed the project on time, but the outcomes of these coding shortcuts and the varying attitudes toward schedule delays among team members turn out to be quite interesting. I will cover them in another article.