We’re used to talking a lot about estimation in the Software industry, mainly on how hard it’s to predict the effort to accomplish an item from the backlog contemplating unforeseen impediments that arise.
However, it’s not the only focus or goal to use it; estimation is crucial to control budget, manage risks, execution progress, and meet the Release Plan by setting achievable schedules and prioritizing work.
What is it and why is it so important?
When the Agile framework is used, estimation is about evaluating the required effort to complete each work item prioritized in the backlog, which is vital to plan the Sprint, along with efficient execution.
What is a Sprint? It’s a defined time-boxed cycle interval that is used to allocate time to complete tasks. Depending on team capacity and available resources for the project, you will be assigning a set of estimated tasks to be done during that interval.
In summary, estimation is the time taken to complete that task considering the defined business and tech requirements. Seems easy right?
Actually, it’s extremely hard even for the most experienced professionals because depending on the size of the project, there are often significant changes down the road, and many technical, business, and even market dependencies.
Although it is not easy at all, it’s key to having success. Let’s take a look at why it’s so important:
- We use it as the main input to build Product Roadmap and Release Plan
- Upper Management relies on estimates to set and track budget and resources
- Predict the approximate time it will take to finish a project
- Enhance launching efforts coordination with the non-SW development team
- Articulate resources and projects along with the organization or customers
- Over Scrum team executing the project:
- Make team accountable for deliverables
- Introduce discipline and methodology across the team and organization
- Improve Sprint Management
- Increase team productivity
However, the most significant benefits to highlight are better Risk Management and an improved decision-making.
What are the consequences of not doing it or doing it wrong?
You have probably heard sometimes that a project (from any industry) differs from the planned execution and gets delayed exponentially, causing, in the best scenario, an exceeded budget or, in the worst case, a canceled project.
This brings several inconveniences, such as:
- Waste of resources
- Misaligned actions between market, marketing, and product.
- Quality impacts to meet target dates
- Product reliability
- Project cancellation with tremendous costs in time and effort.
- Lose a customer and bad reputation
So, what can we do to avoid them?
You hardly will get an accurate estimation in your first shoot, the secret is to apply Agile and Continuous Improvement practices to constantly refine and improve your estimation techniques.
This is more important than a first accurate estimation because as I said, it’s extremely hard to get a first and fixed estimation; but it’s ok, is how Agile works, constantly iterating to down rise risks in small cycles.
As PM or PO, try always to have the highest level of information, business definitions, and understanding over the Problem and customer requirements. Don’t forget to keep an eye on the market and competitors, this diminishes your level of uncertainty when the team estimates a User Story.
As a leader, you should give context to your team and customer, their comprehension is required to refine and manage variables. As you know, team engagement is key and more when we have complex projects or distributed teams.
Use Scrum ceremonies as a base but combined with ad-hoc instances that allow you to find the best-tailored practice for your team or project.
Finally, align expectations with stakeholders; an estimate is that indeed. You will always have the risk of not meeting an estimate. For example, sometimes Customers understand “work effort” or “estimation” as a delivery expected time, so always be sure to discuss over the same ground.
A few tips from the “Trenches”:
I’d like to share a few tips that I think are useful, at least based on my experience.
- Don’t forget to consider time to Scrum Ceremonies, Project Documentation, and Planning, these points are always sub-estimated and are important to avoid deviation.
- Find the proper technique for your organization or team, don’t be afraid to have many different kinds across your organization. Some examples are:
- Use Fibonacci
- User Man hour efforts
- T-shirt Size
- Relative Estimation
- The bucket Estimation
- Many others…
- Agree with the team the estimating ground, speak the same language
- Set common tools
- Swimlanes
- Define and communicate your development process flow
- Breaking down work to be done in the backlog
- Always ask, don’t assume
- Adjust requirements if necessary (client must be informed)
- Align deliver expectations with your customer
- Differ between Delivery (cycle) and Development time estimated
- Take the experience as a degree of confidence (even more with experienced teams)
- Always think in a higher level of integration, don’t isolate your part
- Extra things to integrate
- DoD is helpful not only to ensure deliverables but also to have an integrated view of each piece of the product in the backlog.
- Velocity only works when teams gain experience on similar projects and work together for a reasonable time.
In conclusion, it’s not utopic to have an accurate estimation, but is one of the most challenging points in software development.
Did you like the article? If you would like to go deeper on any point, just let me know!
