I understand the importance of frequent status updates. If someone has a task estimated at a month, you don't want to find at 27 days that the task is off-course and will take two months to complete. These daily meetings are useful as articulation points.
But that's not the point of daily standups. In an "out-of-the-book" sprint, the team has at the beginning of the sprint split the project into small tasks without deciding who is going to do what
. Tasks can be in a small number of states: "not worked on", "being worked on", "blocked" (or impeded), "done". Many teams use a board with columns for the states, and sticky notes for the tasks. During the standup, people move sticky notes from one column to the other. The standup is important to avoid having the same people work on the same task, and to know which tasks can now be worked on because they first need other tasks to be finished. (For instance, if a project involves installing an OS and a database, the task for installing a database cannot be done before the task of installing the OS has finished (which needs to be done after taking the machine out of the box and into the racks (which can only be done after ordering the box (which depends on the task of securing funding, etc)))).
Note also that in out-of-the-box scrum, you don't estimate how long a project will last, then adjust the estimate during the development. It's the other way around. "We have a month (or 2 weeks, or 2 months, usually nothing longer), what can we do in that period". Traditional project management is usually "We want X, we have Y developers, hence we estimate it's going to take Z days", or "We want X, the deadline is in Z days, hence we estimate we need Y developers". Scrum is "We have Y developers, we have Z days. Product owner, split X into smaller X' features, and we'll estimate how many X's we can do". (Note I'm not giving any judgement whether this is a good idea, and I'm sure everyone can come up with at least one scenario where it isn't going to work - I'm just telling what the reasoning behind scrum is).