The Team Should Update the Sprint Backlog Daily
Whether the Team is using a Kanban board or an Excel spreadsheet, there ought to be a canonical source for the Team's Sprint Backlog items. Members of the Scrum Team ought to update the Sprint Backlog at least daily, even if the only change is checking for tasks that meet the "definition of done" and marking them completed.
Mike Cohn says:
During the sprint, team members are expected to update the sprint backlog as new information is available, but minimally once per day.
When you have a Team-managed spreadsheet, this can be done by any member of the Team. Generally, it should be handled by the person who handles the last completed task in a story. For example, if you have a story with six tasks, and the last task is "QA the polish on the fob watch," then whoever is marking that task as done should also check the "definition of done" of the parent story to mark that as completed too.
If you have more of a Kanban-style tracking system, then the Scrum Master can review the Kanban board at the end of the day (or the start of the next) to see which tasks/stories have been pulled from the last column (usually QA or acceptance testing of some sort) into the "done" column. If all the tasks for a given story are in the "done" column, then the story should have met the "definition of done" and the points for those stories should be deducted from the points remaining in the current Sprint--in other words, the "done" column is your source of metrics for the the iteration's burn-down.
Alternatives for Gathering Burn-Down Data
Since a story is either done or not-done, the daily stand-up is a poor source of information anyway since it's a task-dependency meeting. However, not every Scrum process runs like a well-oiled machine. Here are some alternatives, but using them often implies that there's something wrong with your process that you need to fix; these solutions should generally be considered short-term patches on a broken process.
Ask the Team to send the Scrum Master a daily done/not-done email for tasks they've volunteered for.
Note that this moves the status pull out of the stand-up, which makes it somewhat acceptable, but it's covering the fact that task status is not transparent. It's also risky in that it may turn identification of process issues or road-blocks into "holding people accountable" or some other sort of blame game.
The Scrum Master can follow up individually with task performers to see if completed stories meet the definition of done.
There's nothing wrong with communication between the Team or the Scrum Master, or with a check-step process. However, Scrum Master sign-off is a sign of a Team that isn't fully self-organized. Likewise, if the Scrum Master has to validate that user stories are really done means there's a task or process that is missing or not fully visible within the Team's process. Oh yes...and it may also mean that there's a lack of trust on the Team, which is a sign that you have a group of individuals rather than a cohesive Team. There's a lot to consider with this one!
Hold a separate "backlog-grooming festival" daily.
The stand-up is for coordinating intra-day tasks between Team members. However, nothing in Scrum prevents you from having more meetings, or other types of meetings, or from performing status pulls outside the stand-up.
While this particular quick-fix patches over tracking and transparency issues with the Team's process, there's nothing inherently wrong with holding additional process-related meetings during a Sprint. Please note that the time taken for these sorts of status meetings should be factored into the Team's story estimates, as they definitely create (potentially necessary) overhead that needs to be accounted for during Sprint Planning.
The take-away here is that the Sprint Backlog should give you sufficient data to create the burn-down chart. If not, you should definitely consider why the necessary data is missing from the process, and inspect-and-adapt as needed to gather that data without hijacking other essential Scrum processes.
