Actuals VS Estimates - Is this one of the recommended metrics in scrum?

One of the directions that we have received from management is to track the Actuals VS Estimates, and flag the team when we notice that they are exceeding the estimate already. Do you agree?

@Mary Armilyn Gozon, There are no recommended metrics in Scrum, and for that matter, even in the scrum guide.

Could you elaborate what actuals vs estimates means and how it may help? In the end, irrespective, is the Development Team able to deliver a "Done" Increment that is potentially releasable?

If you mean "actual time spent vs the estimated time spent", I would highly recommend that this not be measured or reported on.

• Estimates are a guess based on limited information. They are not a guarantee.
• It leads to "estimation apprehension", where the team will just estimate higher out of fear of discipline or being asked "why is this taking longer than you thought"
• It's hard to measure time spent on a particular backlog item. Even if you make it easy, the team still still be reluctant to do it.

Why are management asking for actuals v estimate? What do they hope to achieve?

It seems like they don't trust the Product Owner to determine what features are valuable.

If you mean something else when you say "actuals v estimates", then let us know.

One of the directions that we have received from management is to track the Actuals VS Estimates, and flag the team when we notice that they are exceeding the estimate already.

Wouldn’t the Development Team know and act on this information already, through the use of projective practices such as burn-downs? If they don’t, isn’t that the problem to be solved?

Ben - your understanding is correct. I meant Actual Hours spent vs the Estimated Hours.

They wanted a way to track if the development team is exceeding the estimated hours, and if yes, then why. In this way the stakeholders can be informed with the reason why we have exceeded the estimated hours.

I do not agree with such a metric. In my experience teams may start to "game" the metric if they know management wants to track this ill advised metric, whether it is Scrum or Waterfall. This usually leads to padding the estimate. Or they will cut quality or take on technical debt. Would they rather the team be effective (deliver value) or efficient (meet actual hours)?

Might this be an opportunity to coach/teach the managers about the empirical process and why it is needed when building a product that resides in the realm of complexity? And that there are no guarantees?

They wanted a way to track if the development team is exceeding the estimated hours, and if yes, then why. In this way the stakeholders can be informed with the reason why we have exceeded the estimated hours.

Why management think estimated hours can/should be equal to actual hours ? 'Estimation'  by definition itself means a rough calculation then whats the purpose of equating it with real actual value ? Can your guesses be right always ? Also like others mentioned what is value of such a metric which involves micromanagement of team? 

Is it possible to get additional information regarding why the management has asked to track actual Vs estimates? Is it for the sole purpose of tracking the progress or does the management wants to use this information as one of the tools to track the profitability and then communicate with the client and bill the client accordingly? 

I would first find out the purpose of this direction. Then, maybe suggest or discuss within the scrum team and management an appropriate way to get the required information.

I once had some managers ask me to track this.  I responded that I would but I only if they agreed to allow me to track the same measurement on things that they did so that I could see if it was a meaningful metric.( I knew it wasn't but I wanted to give them a taste of their own medicine.)  I started tracking the values for the Scrum Team and also for the management team. For the management team I would have them estimate certain activities such as building a presentation for a client that would include forming the presentation concept, building a slide deck, practicing the presentation, revisions, etc.  I would then track the total time it took them.  I would ask them to estimate activities that they would say they would do when I was in meetings with them and then track the actuals. 

In the end, the Scrum Team did a much better job than management.  Management also learned first hand how such a metric was really not useful. It was never requested again.

I agree with everyone above that this metric is bad, very bad. It usually leads to inflated estimates, poorer quality in delivered items and misleading information that hinders any abilities to predict.