Estimations or effort tracking: what is it that teams really need?

Estimation is a hot topic in every software development team/company.

Often the need comes top down awaking many insecurities in the software development teams and causing difficult discussions.

In this post I will tell about our journey to introducing “estimations” and how we used them afterwards.

Last quarterly I was faced with the challenge to introduce “estimations” in our team.

First, I didn’t give it much thought as I think is necessary for planning purposes and asked the team for their opinion straightaway.

The reaction was mixed:

• Some of them felt a little bit oppressed as the team performance is very good
• Others were in favour
• Others just took it as it is

As we started discussing which concerns, they had about estimations we had the following points:

• Maintenance topics are difficult to estimate
• Stories scopes change often during implementation which would lead to annoying adjustments
• Management would use those numbers to make pressure on the team
• The story point unit is very subjective and there were concerns that the team would not have a consistent understanding

After the first meeting I realised that I wasn’t even sure about WHY we needed those “estimations” so I want to talk to the management and asked about the real needs

After some meetings with the management, we agreed that:

• We don’t need estimations for work that is being done in the current quarter. It is enough to track the effort afterwards
• We need to classify our tasks. Our classification come to features, maintenance and technical improvements
• With our effort tracking and classification, we can measure the percentage invested in each type of tasks
• With the classification we know how much capacity we will have for the next quarter so that we can plan accordingly
• To plan future quarters, we do need estimation

The most important takeaway was that estimations were not always needed. It was enough in most cases just to track the effort.

With this information the team met again and agreed on the following:

• Maintenance topics effort will be tracked after the implementation
• Stories and technical topics will be estimated after grooming/planning and will not be adjusted during the implementation. The unit would be story points
• Estimations in quarterly planning will be done with t-shirt sizes that can be transformed to developer days
• For the story points we made a task force to define a unit (Numbers as Fibonacci sequence) and made the exercise to estimate old stories based on subtasks. We made some examples and the task force was on the same page very quickly. This was presented to the team

With these guidelines the team started “tracking effort” until the next quarterly planning arrived and it went as following:

Scope definition

• The product owners brought a bunch of topics to estimate
• The topics were split into different teams to make “quarterly estimations” as t-shirt sizes that were converted to developer days
• The topics were prioritised

Capacity planning

• The numbers of working days per quarter were calculated removing holidays and sick leave
• The topics were assigned to each team showing them that we were respecting our capacities
• Each team created its own roadmap for the quarter and everybody lived happy for ever and ever

Did you ever have this kind of challenges? How were the feelings and impressions within the team?

How did you approach them?

If you like the post, follow me on medium ;)