During the daily standup, some team members have a reflex to start talking on a deep technical level when they have difficulties on a specific task.
Off course, I put on my idiot hat and ask to clarify on a more understandable level.
This is often enough to get to them to honestly say that the task cannot be executed, which I encourage since we try work in a highly communicative environment.
It seems to be a big switch to people coming from a non agile environment (I know, I’ve made that switch only a year ago) to play open cards.
Sure, it ‘s possible that the task cannot be completed as it was defined at the start, but maybe we can look for alternatives, we can discuss with our customer to get more insight, we can hire a specialist,…
There are always other options than just dropping the task.
If the task is part of a user story, it means that it is part of a value-added feature that was prioritized by the customer.
It cannot be the decision of the team to drop it. The team has to advise the customer, explain the issue and alternatives, so he can make a rational business decision.
Ex. Is it valuable enough to spend the extra effort/cost?
What would happen if a scrum master didn’t ask to clarify? Chances are big the task would be forgotten/removed/moved to done. By consequence, the customer would get a feature doesn’t match the 100% value which was agreed upon.
Even worse: is the entire feature still valuable without the missing piece? Maybe not? Again, this can only be decided by the customer.
I believe a scrum master should pay special attention to identify these vanishing tasks, and get them back in the picture.
On a brighter note, most senior developers I know have got the natural reflex to bring a troubled task back in the picture. And off course if the whiteboard is properly used, the troubled task will not get to done, which makes it highly visible.
SkyCoach 
Pingback: Visual Managment - Information radiators « Nick Oostvogels’s Weblog