Steps for more realistic estimations

Estimations in outsourced teams is the series of articles where I’d like to bring more transparency around the approaches as well as challenges associated with assessment of development requirements.

Check out two preceding posts that give a general overview of the process as well as factors that impact estimations:

• Part 1: Process Overview Based on Business Maturity
• Part 2: Why are Estimations Often Off?

As part of this conclusive piece, I’d like to share with you the best practices that will help you provide more accurate delivery timelines. Those are the tips and tricks that helped me when I worked at Flatstack on numerous custom projects peculiar in business ideas, objectives, size and targeted audience. The key aspect is that, despite the differences across applications, processes are similar from the project management perspective.

1. The smaller, the better
   Break down the work into the smallest manageable chunks possible. The smaller the task, the less unclarity there is and easier it is to estimate it in terms of difficulty. Trying to estimate a whole epic (~large piece of new functionality), without going into the guts of it and breaking it down will result in unrealistic expectations. Always.
2. Everybody (who responsible for the area) should contribute
   Being involved in planning, it’s crucial to have teams effective across all brigades and projects within development companies. Only this way projects can stay in stable condition. Therefore traditionally our teams have been “evenly” compiled. This means top management’s major goal was to ensure that all teams are equal in terms of expertise level — mix of senior and middle level developers.
   Within teams it’s great to have senior developers with their expertise, but it’s just as great to have middle/junior developer with their “fresh eye” to question and clarify. So during estimation sessions everybody should contribute, as through team discussions (via Planning Poker) overly optimistic assessments will turn more realistic.
3. Secure some extra time
   Everybody, and especially developers, tend to underestimate the complexity of tasks. Solution is simple — put in some extra time in your estimates. If not on requested objectives, you can always spend it on bonus tasks like: paying back technical debt or fixing bugs. This way it will add value to your project no matter the scenario.
   * Reminder Note:
   Development team should first rate each given task in terms of difficulty points. Then based on historical data like velocity, those points are to be “translated” in a rough equivalent of time frame that will be needed for requirements completion.
   For more details on the estimation process see Part 1 of the Series.
4. Communication is key
   No matter where you are based — the client and the development partners comprise the same team. And everybody has to get it and believe in it. Why are you one team? At least for one reason — you both strive for the product you are working on to succeed! Because if it does, everybody are better off — the client is happy and builds plans, developers are happy and bring those plans to life. However for that to happen, there has to be transparency between the parties: developers need to be aware about all variables of the equation and the client has to be informed about any challenges or unexpectancies. Only in this way the cooperation will be truly fruitful and awesome for everybody!
5. Even if plan is expected to change, document it
   Setting up expectations is key. No matter your long term plans, try to prepare delivery goals document for development period of 3 weeks to 1 month. This will be beneficial for everybody:
   1) client will have a rough idea of what to expect and plan his marketing efforts accordingly,
   2) team will have a more solid requirements with minimum deviations, which will result in greater accountability and confidence.
   By doing so you get a benchmark that will help to evaluate your team’s performance. Followed by retrospective you’ll be able to get worthwhile insights of what worked and what didn’t work over the development cycle. Based on that information, some challenges could be resolved in the future and the best practices applied throughout the entire collaboration.
6. Check-in time!
   Set stages for delivery to check the progress.
   Doing daily standups to get updates from the team members is great — this way you can get a close up look. But every now and then you need to step back and look at the whole picture, this will help you answer the following questions:

• Where do we stand compared to the final goal? Are we half/quarter way there?
  Comment: based on the answer and the amount of time that is left till the deadline you either will cheer up the team on a good progress or think of measures to improve the situation.
• How was our velocity so far?
  Comment: in case of concerns, discuss the challenges that the team might face and come up with solutions. In case of good performance, it makes a good reason to celebrate for some extra team-building-quality-time.

With a little extra care, patience and dedication from everybody involved, complex and often stressful estimations phase will be a bit more enjoyable. Think both ways, reflect on the situation, step in each other’s shoes and it will be much easier to understand where the other person is coming from.

One last thing to keep in mind:

The only time you’ll know EXACTLY how much time the work is going to take is when the work is fully completed… ;)

If you find this post useful please click the 💚 below and be sure to follow me for more articles on software project management!

Check out my previous articles:

1. 7 Ways a Manager Can Increase Development Team’s Efficiency
2. Benefits of Hackathons in the Workplace
3. Misconfig in JIRA for accessing internal information of any company
4. Design conference in Russia’s newest IT city
5. Estimations in Outsourced Teams.
   Part 1: Process Overview
6. Estimations in Outsourced Teams.
   Part 2: Factors that Impact Estimations