As Sklivvz pointed, Scrum does'nt have the concept of left time over single task: im my experience, the tracking the time of single task can stress the developer in strong way (I remember my ex-boss saying me that he would to measure too the time of personal phone call and minutes in toilette :| ) and you consider context's events out your control (for example, corruption of rigid disks of repository machine and lose of the code (Yes, this heappens :)).
I think the the engaged time is an effect of definition of task; more the time is engaged, more the task has some big-effort-point or some unprevedible or unreproducible problematic event in the context, out your control. I go out the stime, why? Difficult in algorithmic? Late in receive the coherent requirements? Problems with configuration of hardware? Lost time in fixing old bug what give effects in new development?
In my experience, I thinks it's better to utilise some standard metric (Function Point, complexity, etc) and see if the task respect the normal values of this metric of the0re's too much difference.
It's the the business task what determines the effort time, not the time what determines the business goals of the software.