In Scrum, all of the effort is focused on looking forward. Actuals, therefore, have no intrinsic value. What is useful about actuals is to use them to refine how a team does its estimates.
Even there, though, a detailed analysis of how individual estimates faired against the actuals is of little value. As a practical matter, most teams learn to live with their estimation accuracy and populate their Sprint Backlogs accordingly.
For instance, let's assume that a team habitually over, over, over estimates tasks. They plan 30 man-days of effort for a 5 person team over a 2 week Sprint (5 * 6 (assuming 60% utilization of the 10 business days)) and find that everything is done by day 4. So when they plan the next Sprint, they say to themselves, "Well, we were able to complete 30 days of estimates with lots of time left over so let's put 60 (estimated) man-days of tasks into the next Sprint and see what happens". Over time, they'll learn how their estimates relate to how much work they can get done in a Sprint. It doesn't matter how bad the estimates are, as long as they are consistent.
Retrospectives are the place where the team sits down and looks at their estimates and how they want to deal with (or not deal with) accuracy. The only important factor, though, is that they figure out the right amount of tasks to put into the next Sprint.