Usually, team members update the burn-down chart daily to reflect adjustments to the amount of remaining work. Such updates reflect a desire to have as good knowledge as is possible about the effort remaining. These estimates are made in mid-stream and reflect increases that arise from emergent requirements. However, given that one emergent requirement has been discovered in a task doesn’t imply that no others remain. While the confidence in an estimate usually improves with each revision and with continued work on the task, unusually wicked problems seem never to converge.
On the other hand the Product Owner is not centrally interested in partially completed work, only in items that are done and potentially shippable. Since the goal of Scrum is to achieve the Sprint target agreed with the Product Owner, and to reduce risk, the focus should be on done. Emergent requirements increase risk, and the Product Owner is certainly interested if estimates expand. Because there may always be emergent requirements, any estimate of remaining time based on work mid-stream in a task has a higher degree of uncertainty than the relatively risk-free estimate of zero remaining time for done items. In theory, it is possible for the remaining time on a burn-down chart to be quite near zero, yet to have few (or perhaps zero!) tasks in the done state.
Therefore:
Update the Product Backlog in only two cases: reducing the amount of remaining known work if the task is done; and increasing the amount of known work if the task grows in size due to emergent requirements or other insights gained during the Sprint. Do not reduce the amount of remaining work that arises from progress on partially completed tasks.
I'm guessing the size of the tasks need to be small (1 day?) and at most 1/2 the size of the sprint so that you don't have a velocity heading northward for a significant part of the sprint.
