性质的变化，团队需要每天至少对工作进行一次新的排序，以超越平庸。
除了工作之外，团队成员缺勤（如病假）可能会迫使团队重新考虑其工作计划。
另一方面，过多的重新规划和重新估算会浪费时间，让开发人员窒息。但太少的重新规划和重新估算会导致阻塞，导致计划延误或过时，不能体现实际情况。
个人可以很快做出决策，但在团队环境中，个人不可能孤立地做出决策。你需要与每个可能受决策影响的人接触。与相关方取得一致需要时间。
个人可能需要把问题提给整个团队。但可能很难找到这样做的机会。特别是，在团队解决问题之前，这些问题仍然是阻碍。
解决方案
因此：
每天有一个简短的活动来重新规划Sprint，以优化1. 达到冲刺目标的机会，2. 完成所有Sprint Backlog条目的机会。严格遵守时间盒，以确保专注于当日计划，避免剥夺开发人员的宝贵时间。专注于接下来一天的工作，但同时也要对Sprint的剩余工作心中有数。
将会议时间限制在15分钟以内。团队按照自己的时间盒管理自己，如果需要，Scrum Master将强制执行流程的这一方面。许多团队在会议期间站立以强调会议的短暂性。团队可以在之后继续处理每日Scrum会中的未尽事宜，但每天此会议如果花15分钟以上来做重新规划，就说明需要持续改善（Kaizen）或突破性改善（Kaikaku）。
每个开发人员都必须参加，这一点至关重要。在开发人员因疾病或冲突而缺席的罕见情况下，找其他人顶替参加可能没有意义，因为最晚他会在下一次每日Scrum会上获得最新信息。
为了制定计划，你必须知道自己在哪里，以及有哪些问题在阻碍你。你需要知道全局。一种受欢迎技巧是让每个开发人员回答以下三个问题：
昨天我做了什么帮助团队实现Sprint目标？
今天我将如何帮助团队实现Sprint目标？
我是否看到任何阻碍我或团队实现Sprint目标的阻碍？
请注意，当开发人员提出阻碍时，大家可能很自然会想要去深入研究这些阻碍并探索可能的解决方案。但这次会议是为了重新规划和决策，而不是为了解决问题。相反，一些开发人员可能会同意在白天聚在一起制定解决方案，这样就不会浪费其他人的时间。他们将在第二天的每日Scrum会上报告他们所做的事情。
当然，这些阻碍往往会需要对计划做出改变。因此，团队对当天的计划做出调整，以疏通阻碍。这是这次会议的重点之一。
这是开发人员的会议。在开发人员的邀请下，开发人员以外的人员可以参加每日Scrum会。开发人员可能会认为Scrum有一种透明的精神。但另一方面，局外人的存在可能会影响会议。在任何情况下，只有开发人员才需要高度参与此会议。本段叙述适用于产品负责人以及任何其他非开发人员。
Scrum Master可以随时参加会议，特别是在组织中Scrum的早期，主要是为了确保大家遵守时间盒以及流程的其他方面。但是在这些会议上，很多开发人员往往会将Scrum Master视为经理。为了避免此情况带来的负面作用，Scrum Master最好不要参加这个会，或者在出席会议时扮演一个隐身Scrum Master的角色。
每日Scrum会导致Sprint Backlog以及相关的信息雷达做出更新。然而，理解每日Scrum会是一个重新规划的会议而不是状态会议是至关重要的。信息雷达上的信息是会议的副产品，而不是会议的目的。
进一步说明
每日Scrum会的精神是对现实的检验：我们会实现Sprint目标
