We're using scrumworks (a scrum backlog tool) at my current assignment, and i have to say i'm honestly really impressed with it. BUT...

If you don't understand agile and are told to 'burn down' your hours on a daily basis you'll find most people think that means "i worked 8 hours so i burn off 8 hours on this task"

WRONG

Here's why in two parts.

One, in scrum, things are either done or they're not. I am a purist in this regard...this is a binary operation. It's either done or it's not. (See defining done in ken's book). If you're having to 'burn 8 hours' off a single task... your problem is your tasks are too damn big to be managable! Try decomposing further!

second, your goal isn't to create a perfect looking burndown... your goal is to represent the work you're actually doing in the best means possible. This means always putting in the number of hours that you have remaining. This means that if your task said 4 hours this morning, but at the end of the day you think it has 4 hours left to go, you leave it at 4 hours. Basically every time you estimate a task you need to be estimating how much time is left to do.

You may have learned something new today that you didn't know about the day before on that task.  Just today for example i was suppose to be adding some account detail information on to an asp.net page and i figured "this is going to be a simple update, some format, some text changing... NO! i was wrong. What i thought was going to be 15 hours of work was actually many many tasks with 4 hours each.

Now as management, you have to do the right thing here and not come down on the developers for 'finding' out this change in information. you have to use the information to your benefit by figuring out what happened and addressing it properly. Maybe you need to remove some items off the sprint to bring the burndown back in line with your sprint end date? Maybe you actually have to bring more items in from the product backlog?