Software Estimation Best Practices

Agile Series Part 3: Embrace Change

“The only thing that is constant is change” ~Heraclitus

This proverb is often told to individuals (like me) who love to see a project follow a plan from start to finish.  I’ll be honest, I’m a planner. I’m thrilled when the plans I put in motion actually work out the way I intended.  These are the moments when I retort, “the only people who like change are wet babies.” However, more often than not, something changes, which throws off my entire plan and forces me to not only revisit Heraclitus’s proverb but also rethink my plan entirely.

Building software, particularly in Agile development, is no exception. In fact, the second principle of the Agile Manifesto states that developers should: “Welcom[e] changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

It would seem, then, that this principle would disappoint any planner working on an Agile team. Why bother creating a development plan if you know the stakeholders are going to change their minds about their desired features at the last minute? While we’re on this subject, if the requirements are going to change from one iteration to the next, why bother estimating the project at all?

I’ll tell you why: the bottom line still matters to stakeholders. They still want to know how much functionality to expect for the money they are spending and when that software will be delivered.  Mike Cohn illustrates this very well in his blog post about estimation in Agile projects. To summarize, he states that, “estimating is a way of buying knowledge. If having additional knowledge will lead to different decisions, then acquiring that knowledge might be a good thing to do.”  Making high-level estimates allows Agile teams to provide stakeholders with more confident predictions of the project’s lifecycle, which ultimately may affect project funding.

So now that we know why we should still do estimates despite the changing requirements, how can we do that while also satisfying your inner planner? SLIM-Control is an estimation tool that allows you to track the progress of a project while also forecasting the project’s future. By entering data about the actual progress of your project, you can predict when it will reach various milestones (See Figure 1).

Figure 1: SLIM-Control Core Metrics View
Figure 1: SLIM-Control Core Metrics View

As you can see from the figure, you can track the actual project performance against the projected curve.  Anything in the green means your project is on track, yellow indicates the project is veering off track, and anything outside the yellow means the project is in trouble.

Suppose the scope of the project changes due to a last minute customer request. You can adjust your project plan in the Forecast Assumptions tab by inputting the new information, in this case changing the original 38 story points to 42 (See Figure 2).  

Figure 2: Forecast Assumptions View
Figure 2: Forecast Assumptions View

This will create a new forecast which you can then convert into your new plan. As you can see in Figure 3, the dates for project milestones have changed to accommodate the change request.

Figure 3: Convert Forecast into a Plan
Figure 3: Convert Forecast into Plan

This feature allows Agile teams to make initial plans and then adjust them as requirements change. Project managers can share these forecasts with stakeholders so they know when they can expect to reach the different project milestones.

Creating high-level estimates throughout the project and tracking your progress can reduce uncertainty and help team members make more realistic plans when requirements change. Forecasts such as these will help team members manage the changing requirements, giving their customers a competitive advantage.  

So to quote Winston Churchill, “to improve is to change; to be perfect is to change often.”  I hope this post brings you more security about embracing change in your projects.

Blog Post Categories 
SLIM-Control Agile