skip to Main Content
+44 7459 720984 info@edgeagility.com

Side Effects Of Tracking Estimates Vs Actuals


In one of my earlier assignments as a Scrum Master in a software house, management had built dashboards that were tracking each developer’s total estimated time as well as actual time that each developer has spent performing tasks.

Moreover, timesheets were integrated with the Sprint Backlog management tool. So every task and every hour needed to be recorded so that people’s actual time towards the work can be tracked.

Scrum Master’s responsibility was to have a close eye on these metrics and create a bi-weekly report for the management so that there was a satisfaction that every ‘resource’ is fully utilised and ‘busy’ enough.

I was spending a good few hours a week, not only to badger development team members to update their tasks but also to keep tracking these ‘Estimate Vs Actuals’ metric.

‘Estimate Vs Actual’ calculates the difference between estimates provided by developers during the Sprint Planning event and the actual time spent on completing tasks during the Sprint.

If there was a big deviation, management was asking Scrum Master or the Development Team ‘why this has happened’ and the quality of the Sprint Planning was questioned.

If the team is identifying new tasks during the Sprint, it was considered as bad Sprint Planning.

Apart from losing time, money, and effort in measuring these activities, this also led to some long term issues:

Distrust Between The Team and Management

In my organisation, the outcome of these practices was not great. The Development Team members’ aim was more toward proving that they are on track. Aim shifted from collaborating and creating the ‘Done’ increment towards making charts/reports look good. Some even started gaming the numbers so that the management would leave them alone.

Management was believing that if everybody is busy but still not delivering anything then they must be telling lies.

These behind the back talks start growing distrust between the Development Team and the management.

Obsession with productivity leads to micromanagement, a key source for distrust.

Loss in Transparency

Considering Sprint Backlog as an artefact to manage productivity also leads to the loss of transparency. It starts creating an illusion that everything is ‘fine’ but the reality is only known to the Development Team members.

Considering Sprint Backlog as an artefact to manage productivity leads to loss of transparency.

Poor Quality Increment

Another bad behavior that starts developing is that the Development Team starts cutting the corners so that estimates meet their actuals. Focus starts developing more towards completing individual tasks. This ends up with the poor quality of the integrated work.


Possible Solutions

Accept The Complexity

In my opinion, we all would have faced situations where tasks estimated to finish in a couple of hours actually end up in days/weeks to complete. That is the nature of the complex work.

It is impossible to make perfect predictions in complex work such as product development. In a complex environment, knowledge emerges and hence the work. The best way to deal with complexity is to inspect and adapt plans. Embrace empiricism.

Sprint Backlog emerges as the Development Team performs work to meet the Sprint Goal.

Let The Team Manage Itself

The Development Team members are knowledgeable workers and they work best when they are self-managed and organised. Make them realise that they own Sprint Backlog and other related complementary practices such as Sprint Burndown Charts, Scrum Boards. Provide them the trust that these are for them only and emphasise the importance of creating transparency in the Sprint Backlog for their own benefits. Remind them of these benefits and they will self-organize.

Provide Alternatives To Management

Changing the way management and leadership work is not an easy task. They need the information to make decisions but because they have no alternatives, they fall back on something that they have learned and used over the years- measure productivity.

‘Done’ product increment should be the primary source of measuring progress. Evidence-Based Management is a great alternative for metrics for management.


Endnote

By focusing too much on productivity metrics, organizations can cause

  • Distrust among management and the development team members
  • Loss in transparency by creating an illusion that everything is alright
  • A poor quality increment as team members are focusing on more individual performances

Few possible solutions to the above problems

  • Accept that work emerges in the complex environment and hence, it is impossible to make perfect predictions
  • Create an environment where teams can self-manage and organise
  • Measure the right value-based metrics such as Evidence-Based Management
This Post Has 0 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *