How to become better at software estimations (Part 2)

In the previous post, I outlined what software estimations are and what they consist of. Now comes the good part. From our experience at Code Runners, we’ve gathered some useful practices that makes estimating faster and more accurate.

For example, grooming sessions are meant to clarify the objective and set the right direction. You should encourage developers to ask every question possible in order to refine the specification. It needs to be stressed that there shouldn’t be any shadow left as to what needs to be accomplished. The final output from the session needs to be a user story that is clear and understandable. As I mentioned in a previous post — never make assumptions about the user requirements.

In the pre-planning session, make sure to check the existing code and how it behaves. This helps you analyse the complexity of the task from a technical standpoint by considering the impact the new feature will have on existing features. There are often dependencies that cannot be figured out without going through the code base first. The output should be a story that is clear from an implementation point of view. If the required functionality is to large to estimate, it can be broken down into smaller chunks that are then easier to evaluate.

A technique that we often use to estimate projects is comparing to previous similar projects that we’ve done. This is why we like to focus on projects in specific industries — with each successfully completed project, we get better and better at every step of the development process, including the estimation. Another trick is adding a 20–30% buffer, depending on the complexity of the project and the clarity of customer requirements. (Update: Thank you James Kingsbery for the advice on the estimation buffer)

There’s a somewhat controversial practice that companies often use called “planning poker”. It involves members of the development team writing their personal estimation on a sheet of paper and showing it together at the same time. What follows is a discussion of each personal forecast and justification how the team member decided on this amount of time. I call it controversial, as it may sometimes backfire, if developers start competing by reducing their estimations. Knowing this risk can help companies avoid it by communicating with the team the importance of ignoring personal egos in favour of a more effective work process.

Technical vs. functional stories

Previously, we mentioned the importance of having a clear user story before making an accurate estimation. But functional stories can be very different from technical ones and keeping this difference in mind can add much to a team’s estimation capabilities.

Firstly, functional stories are much more tangible and better defined. They can be broken down in specific smaller tasks or pieces of functionality. Those stories can also be isolated to a specific part of the whole system. Making them so detailed and specific gives developers more information about the impact the new code will have and makes it easier to evaluate potential regressions.

Technical stories, on the other hand, are much more vague although the final objective is defined. This makes them considerably more difficult to assess and far more likely to cause unforeseen issues in the system. They’re also more likely to include unknown technology, which also causes unexpected problems during development.

Effective vs. actual hours

Another thing that can help a team become more accurate at their estimations is considering the amount of effective working hours contained in actual hours. Generally, the number is somewhere between 6 and 7 hours at most. This amount is further reduced if the person is also involved in other tasks such as project management, Scrum master activities, support to other team members, integration and deployments and additional meetings.

Taking it a step further, teams should also consider how many effective days are included in a 1 week development sprint. Taking out the time for planning sessions, grooming sessions, a demo, daily stand-ups and retrospective sessions (where applicable), time left for actual coding is greatly reduced.

Definitione of “done”

At our recent internal workshop, we also discussed when a certain task is considered done. We believe it’s extremely important, as it further makes estimations more accurate, by defining the exact point when the “timer” stops. For any given feature to be finished, the following boxes must be ticked:

Analysis from technical perspective is complete.
Global design (architecture) is complete.
Detailed design (coding) is complete.
Unit test is complete.
Code review is complete.
Integration is complete.
Basic integration tests are complete.
Basic regression tests are complete.
Documentation (e.g. API description update) is complete.

By introducing this list, our team can clearly mark their progress and see what really is done and what is left. We also introduced a list of phrases that strongly convey something is definitely not done.

“It works, but…”
“It’s done, but I just have a couple of things to finalise.”
“It’s ready, but I haven’t tested it.”
“It’s done, but I need a few more hours to check for edge cases.”
“It’s OK, but there are a lot of conflicts, so I’d probably need a day to merge.”
“It was working before.”
“It works on my machine.”
“It’s ready. (three days later) OK, now it’s ready”

Conclusion

Estimations are hard. It takes time and practice to do them right and even then they may end up way off the actual time line, because of unpredicted circumstances. There are various methods and techniques teams can use to make more efficient estimates, but the first step is acknowledging the importance of estimations and taking active steps to train your team to become better at it.