1.Story Work Flow:

1) 新建的Story为"To Do"状态；

2) BA在跟BU确认需求后，会开始System Requirement的编写，此时Story为"Requirement-Doing";

3) BA完成System Requirement, Story为"Requirement-Review", BA添加Label "Pending_BU_Approval";

4) 之后BA会跟BU进行System Requirement Walkthrough，确认SR没问题，PO会添加Label "BU_REQ_Confirmed"; (PO或BA将story状态改为"Requirement-Done")；

5) BA在internal SR Walkthrough Meeting上给开发团队讲需求；开发理解后，再开Kick-off meeting将自己对story的理解讲给BA确认，确保双方对于需求的理解一致；

5) 开发拿到BU确认后的story，将Story状态改为"Construction-Todo"。在上个Sprint结束前，需要将Story分配给对应的Scrum Team，Story Prticipant字段需要由Tech Lead添加自己和相应开发的名字；

Tech Lead/开发在story下建相应的sub-task，并设置sub-task的Assignee，Due date和Original Estimate字段，Tech Lead对sub-task进行review;

6) 下个Sprint开始时，开发开始story的tech design工作时，将Story状态改为"Construction-Doing",并每天根据实际情况更新sub-task和Story状态；

*design类sub-task完成后，需link tech design的link或上传文档, sub-task状态改为"In Review", assignee改为“Tech Lead”，由tech lead在tech design review meeting后将状态改为"Done".

*开发自测的UT/SystemTest的sub-task，在完成后需上传UT result 和 desk check结果，完成后sub-task由开发将sub-task状态改为"Done"，并将Story状态改为"Construction-Done", assignee改为BA.

7) BA review sub-task上的desk check结果，有问题在sub-task上或offline沟通；若没问题，则在Story上加Comments说明desk check通过，并将Story状态改为"SystemTest-Todo", Assignee改为“Eric”(PO). 之后由PO review desk check结果，并完成Story后续流程。

2. Defect Work Flow:

1)测试新建Defect，默认状态为“Open”，Assignee为tech lead - “King”或"Roger"; Scrum Master需关注Board上defect状态，将新建的defect根据feature和资源情况分配给对应开发。

2)开发拿到测试新建的defect，开始Investigate，将Defect状态改为"Investigating",请注意defect处理请遵循SLA，较复杂的可以除外，Defect当天处理不完的情况，需下班前在Jira Defect上加comments说明下情况和进度。

    3)开发fix完defect或处理完invalid defect时，需做以下操作:

a. 填写Root cause analysis字段，参见Jira Root Cause Category Guideline

       b. 加comments说明做了什么处理

c. defect状态改为"Systemtest-todo"

       d. Assignee改为测试人员