Better Than Estimations

Relying on estimations in software projects is dangerous. Unfortunately, many projects keep doing it and often fail as a result. The underlying assumption is that developers are capable of estimating the unknown. However, I have never met a team that consistently produces reliable estimates.

Hence, I want to share an alternative approach with you that is more effective than planning by estimations. It is a combination of three essential concepts that work very well together:

1. Prioritize Clearly

Usually, there is much more work available than can be completed in the next few days. Therefore, we need crystal-clear priorities. We must not try to do everything at once. Ironically, when everything is considered important, nothing is really important at all. There should only be one or two tasks that have the next highest priority. Challenge your assumptions and those of your stakeholders, product managers and business experts.

In order to determine priorities, it helps to think about impact, risk and dependencies. Do you want to validate a product idea? Then it might not be a good idea to invest in comfort features. Focus on the next minimal core functionality instead. Do you have to meet an external audit or compliance deadline? Then it is probably better to focus on documentation and security bug fixes instead of improving the user interface. You get the idea.

2. Focus on Small Steps

We need to keep our steps small to stay flexible and incorporate feedback. Hence, we need to break our tasks into smaller pieces. We must ensure they are reasonably small. As a rule of thumb, you should have a good idea of the rough steps that are involved in a task. Imagine a small bullet list for the individual steps of a task. If you cannot imagine such a list, the task is probably too big or needs further investigation, which can be a small task in itself. The goal is to keep your tasks small enough that we can complete them in a few hours or days.

If, on the other hand, a task is large and takes weeks or even months to complete it, all kinds of problems can result from it. In this case, we cannot react to priority changes. We cannot get any feedback, as there is nothing to show or test. Plus, integrating large changes into a code base is often very painful. When you are working on a task and discover that it is much more complex than expected, consider breaking it down further and completing the part that you have already implemented. Make a small cut as soon as possible.

3. Measure Progress Instead of Effort

Keeping our tasks small enables us to measure our progress towards a larger goal. This is better than measuring effort and comparing it to estimates. After a while, we can answer questions like these: How many features have been implemented by now? How many tests did we manage to complete last week? How many tasks, on average, are we able to complete with our team?

These numbers, measured over a longer time frame, are more meaningful than some random estimations and time logs, in my experience. After a while, you get a good idea of what your team is capable of, assuming you keep your steps small.

Summary

Combining the principles above is much more powerful than all the estimation techniques in the world. Most importantly, it ensures that you are actually getting meaningful work done. Applying the concepts above does the following for us:

1. We are focusing on the right things by prioritizing and not wasting time on nice-to-have tasks (unless there is nothing more important to do)
2. We stay flexible enough to incorporate changes and react to feedback by working incrementally in small steps
3. We know how fast we are moving by measuring our progress in terms of tasks completed (that can be features completed, bugs fixed or other things)

Now, I am curious to know about your experience with estimations and alternative concepts. Have you applied similar techniques to your software projects? Can you recommend any alternative approaches?

#SoftwareEngineering #Estimations #ITProjects #Uncertainty