敏捷教练SM在和每个人确认任务卡片时，需要注意以下几点：
4.1 目标一致：
做最后确认，确保所有人都清楚本次里程碑的目的和逻辑细节，只有理解了业务细节才能很好的拆解任务卡片，确保不丢失业务逻辑；
4.2 任务拆解：
单个任务1天为最佳，最多不能超过2天，绝大多数的任务都是可以拆解的，很多人无法拆解是没有掌握正确的拆解方法，我们可以按照页面数量、接口数量、制作步骤等方法进行拆解。
例：我们要画一张原画，正常需要7天，我们可以按照步骤拆解：
找参考（可省略）→ 画草稿 → 画线稿（将草稿清晰化）→ 上色（上底色、上阴影色、上第二层阴影色）→ 加特效（画背景、光影）→ 优化细节 → 完稿。
拆解到人天的好处就是让每个人都知道每天要完成什么内容，工作目标清晰透明，验收时只有两个结果是和否，不存在模糊不清的进度（比如完成30%这种），既让成员有一定压力，也能够有效的减少工作不饱和的情况；
第二个好处是SM每天都知道谁交付了什么，如果没有完成第二天也能及时风控，而不是等几天之后才发现某人完成不了；
4.3明确信息：
任务卡片里的内容要清晰准确，要有量化的内容，不能用模糊不清的概念，SM要能够理解每个卡片上交付的内容，如果不理解需要让成员修改，并检查每个人卡片上三要素是否齐全；
例如
错误：完成接口的开发（不具体）
正确：完成用户注册5个接口开发
4.4消除瓶颈：
检查卡片时需要关注是否包含了所有的需求，是否有估算时长与预期、或和以往类似功能时间严重不符的任务卡片，单人的任务时间是否过长，评估整体里程碑时长是否过长；
如何评估任务估算过长？
里程碑的总时长是否和你预期的相差过长，如果是，和团队表达你的想法，一起寻找瓶颈点
培养自己的直觉，和历史同类任务进行对比进行判断
把握不准的，可以使用同岗位使用扑克牌估时法，找出差异大的估时逻辑
在前几次的里程碑中，观察和评估每个人的工作效率，用于后期对每个人的估时进行判断是否有很大的不饱和情况
那如果有人任务估算过长，应该如何处理呢？我们可以从以下几个角度进行分析解决：
信息缺失：有可能是对所负责的任务还不是很了解，或把解决方案想复杂了，或对项目不熟悉，不知道有些方法已存在，可以直接使用等等，这些都可以通过深度沟通来解决；
任务拆解：尽可能的拆细，查看每一天的任务的工作量是否饱和，直到无法再拆为止，拆到一个点就很容易评估时间；
能力不足：一些新人刚开始可能不知道如何拆解任何和评估，这个时候需要更资深的开发来进行辅导，梳理业务逻辑，输出合理的卡片，辅导2~3次之后即可解决该问题（如果没有资深开发可以考虑招聘一个，一个经验丰富的开发，对于消除瓶颈有极大的帮助）
态度问题：极个别的情况可能是员工的工作态度问题，态度问题很难在会议上进行解决，短期内也不太好解决，这时需要PO使用权威来推进，适当给予压力，日常工作中要进行引导，若发现还是没有改变的迹象，需要考虑替换；
4.5打通关联：
SM需要全局观察每个人的任务排序和时间，观察上下游任务衔接情况，合理调整顺序，确保任务的连贯性，尽早的交付可供测试的软件。
4.6交付承诺：
任务卡片确认完毕，明确三个时间节点，所有人达成共识，将任务按照优先级展示在看板上，输出里程碑计划表，全体成员承诺交付结果。
5.每日站会
里程碑确定之后，通过每日站会来推进项目进度，由SM发起，全体成员参加，PO和其他需求方选择性参加（但只参与、不说话），每日站会是快速专注的会议，用来分享进度和迭代看板进展，每个团队成员就他们将要完成的任务对其他人口头承诺；
所有人围绕在看板周围，每个人轮流上前回答一下三个问题：
昨天我为团队做了什么？
今天我将要做什么？
我需要哪些帮助？
回答完毕之后将已完成的任务移入Test泳道，将今天的任务移入Doing泳道。
一个有效的站会需要做到以下原则：
固定时间、固定地点，养成习惯，迟到的人要有惩罚
全员参与、站立开会，保持专注，时长控制在10~15分钟
三个问题、更新进度，不要讨论技术问题，不要转移会议话题
注意聆听、回应问题，别人在讲时其他人要注意听，需要帮助时相关人员要及时回应
6.Sprint冲刺评审会
在开发完毕后，即将交付上线之前，由SM发起，全体成员参加，开发团队将可交付物演示给需求方，需要方进行功能评审，收集反馈意见；
评审会并不是必须的，但Scrum团队要经常和需求方保持信息互通，确保接受到最新的市场动态和用户反馈，交付的产品满足利益相关者的期望，让团队的产出有价值。
7.Sprint冲刺回顾会
每一个冲刺会完成后，都要举行一次冲刺回顾会议，在会议上所有团队成员对本次冲刺进行反思，包括：什么进展顺利？缺少什么？需要改变什么等等；
冲刺回顾会是针对迭代末期进行的时间盒会议，目的是帮助团队如何提高他们的工作效率和改进工作方式，就未来的迭代改进计划达成一致；同时梳理以往的项目缺陷和债务，对用户故事进行审视，是否需要新增、删除、修改用户故事，对用户故事进行优先级排序；
需要注意的是，让团队自己反思，PO尽量不参加，或者参加也尽量少说话，反思时要找出明确的问题和意见，不要情绪化，切勿开成批斗会。
Scrum敏捷流程让在早期发现可能的问题，可以用更快更小损失应对问题，“没有问题被扫入地毯下”，Scrum鼓励每个团队成员清楚的描述自己所遇到的困难，其他成员积极的响应解决，降低项目风险，SM必须有预警风控能力，能判断出可能的延迟或者偏差；
至此，正式踏上了敏捷之旅；
然而，敏捷之路，不可能一帆风顺，团队只有在不断遇到问题解决问题才能快速成长。
