Often, when we ask people whether a task is done, they answer: "Yes". If we then ask, "Is it really done?", they answer: "Well, almost". This is what we call the 90%-syndrome: If 90% is done, people start working on the remaining 90%. This is an important cause of delays. Therefore, it is imperative that we define when a task is really 100% done, and that we insist that any task be 100% done. Not 100% done is not done.

In a team we help each other getting our commitments right. When coaching, I use: "Promise to do nothing, as long as that is 100% done!" to convey the importance of that it's not about doing more than one can, and about completely done. Only when working with real commitments, developers can learn to optimise their estimates and deliver accordingly. Else, they will never learn. Project managers being afraid that the developers will do less than needed, and therefore giving the developers more work that they can commit to, will never get what they hope for, because without real commitment, people tend to do less.

In TaskCycles, we ask for tasks to be 100% done. No need to think about it any more. Every week, priorities may be reconsidered based on what we did the previous week. We decide what the best goal is to have achieved by the end of the next week, and individually people decide what they think is best as their contribution to achieve this goal. They check how much time they have, how much time they need, and see whether they actually can achieve what they think has to be done. If other team-members doubt whether (s)he can actually achieve that, we ask questions, like: "I couldn't do that in the time available, can you really?", or "Last week you couldn't finish all, what makes you think you can succeed now?". All to help each other to be successfull by the end of the week. At the end of the weekly planning we ask for commitment: "Do you really think you will have done all of this by the end of the week?", and if we see any doubt in the eyes, we say: "Do you really?" All we ask from each other that what we 'promised' at the start of the week will be delivered. If we tell someone what to do, there is no commitment. If we let people completely freely decide what they can and will do, they quickly learn what they can commit to and deliver, and what not. This is the only way to get true developer commitment.
At the end of the cycle I sometimes use the 'mirror': In the mirror the developer sees himself if he failed in fulfilling his commitments. If I would have told the person what to do, (s)he sees right through the mirror and only sees me. With commitment, we can learn if we failed. Without commitment, there is not much learning.