如何進行Sprint Planning (下)
How To Implement Scrum In 10 Easy Steps - Step #4: Sprint Planning (Tasks)
http://www.agile-software-development.com/2007/10/how-to-implement-scrum-in-10-easy-steps_11.html
前面在sprint planning meeting中, 已經釐清好backlog的reuqirement, 接下來就是規劃要完成這些reuqirement的細部工作項目, 以及所需的時間.
1. 和前面釐清需求會議的關係
(1) Although Part 2 of the workshop can follow straight on from the first part, it is sometimes helpful for there to be a short gap between the two meetings; maybe 1 day.
(2) This allows time to clarify any outstanding questions arising from part 1 of the workshop before proceeding with the next step.
2. 有哪些角色需要參加工作項目規劃的會議
- Business Analysts if you have them. Testers if you have them.
- ALL Developers on the Scrum team for the product.
- The Product Owner and any customer, user or business representatives need not attend this part (part 2) of the Sprint Planning workshop, as it’s likely to be more technical in nature and is more about the team working out how the selected backlog items will be delivered.
- However, they should be welcome to attend if they wish, which may help their understanding of what’s involved to deliver the features, and may help if any further clarification is required as the tasks are discussed and estimated.
3. 設定你有多少時間可以花在這個Sprint
(1) Calculate the team’s Sprint Budget: the available number of hours the team has to work on the Sprint.
(The available hours in the Sprint Duration X the number of full-time people in the Sprint )
+ (For people who are working part-time in the Sprint, include the number of hours they can commit to)
- (Any reasonable deductions for time that team members will not be able to spend working on the Sprint)
(2) Deduct holidays, any known meetings, any time likely to be spent working on other projects, etc.
(3) Based on past experience, deduct a reasonable amount of time for support, if appropriate.
(4) Make sure all these calculations are transparent and visible to all.
4. 把需求展開成真正處理的工作項目
(1) Go through each Product Backlog item selected for the Sprint. Break the requirements into tasks.
(2) Tasks may include the traditional steps in a development lifecycle
- For instance: Design, Development, Unit Testing, System Testing, UAT (User Acceptance Testing), Documentation, etc.
(3) Remember, agile software development methods do not exclude these steps. Agile methods just advocate doing the steps feature-by-feature, just in time, instead of in big phases.
(4) Each of these tasks, especially development, may be broken down further.
(5) Include all tasks necessary to make the Product Backlog item 100% complete
(6) Agree as a team on your definition of done, so everyone is aware what will have to be completed and included in the estimates.
(7) State tasks as deliverables, if at all possible.
- Deliverables are more measurable than tasks.
- Instead of describing what you’re going to do, describe what you’re going to deliver.
5. 以小時為單位來評估你的工作項目
(1) Keep tasks small. Estimate all tasks in hours. Estimate each task as a team.
(2) Ask everyone what they think, in order to identify missed tasks, or to identify simpler solutions.
(3) Ideally task estimates should be no more than 1 day.
(4) If an estimate is much larger than this, the requirements should be broken down further so the tasks are smaller.
(5) Keeping tasks small enough to estimate at less than 1 day has some specific benefits.
- Breaking tasks down into very small chunks means they are easier to estimate. The accuracy of your estimating will be improved as a result.
- Tasks less than 1 day are more measurable in the daily Scrum (stand-up meeting). 1 day tasks are either done or they are not.
6. 承諾哪些backlog要在這個sprint中完成
(1) Add up all the task estimates for the selected Product Backlog.
(2) If they are significantly over the team’s Sprint Budget, reduce the number of Product Backlog items selected for the Sprint.
(3) Remember the Product Backlog was in priority order, so if possible it should be the lower item(s) on the backlog that are removed from the Sprint.
(4) The remaining list of estimated Tasks – those tasks needed to complete the selected Product Backlog within the Sprint - is your Sprint Backlog.
(5) The team should commit to delivering the Sprint Backlog.
7. 找出後續要作的工作
(1) Sometimes teams under-commit or over-estimate. Stranger things have happened! :-)
(2) In my experience this is quite common when teams are new to Scrum.
- This can sometimes result in an over-cautious approach to the estimates.
I think it’s because they are unfamiliar with the process and potentially out of their comfort zone initially. They may not have had much experience of estimating in the past.
And they may not have been asked to commit to their own delivery before.
This can sometimes result in an over-cautious(謹慎的) approach to the estimates.
(3) Always include some additional scope in your Sprint Backlog, over and above what you think can be achieved.
- This is important in order to have something ready if the team delivers early, as the Sprint should ideally remain a fixed length.
- Clearly identify these items as Stretch Tasks.
(4) Should never expect Stretch Tasks to be reached.
- No-one should ever be beaten up if Stretch Tasks are never reached.
- And if you do manage to complete any Stretch Tasks, this should be cause for celebration!
How To Implement Scrum In 10 Easy Steps - Step #4: Sprint Planning (Tasks)
http://www.agile-software-development.com/2007/10/how-to-implement-scrum-in-10-easy-steps_11.html
前面在sprint planning meeting中, 已經釐清好backlog的reuqirement, 接下來就是規劃要完成這些reuqirement的細部工作項目, 以及所需的時間.
1. 和前面釐清需求會議的關係
(1) Although Part 2 of the workshop can follow straight on from the first part, it is sometimes helpful for there to be a short gap between the two meetings; maybe 1 day.
(2) This allows time to clarify any outstanding questions arising from part 1 of the workshop before proceeding with the next step.
2. 有哪些角色需要參加工作項目規劃的會議
- Business Analysts if you have them. Testers if you have them.
- ALL Developers on the Scrum team for the product.
- The Product Owner and any customer, user or business representatives need not attend this part (part 2) of the Sprint Planning workshop, as it’s likely to be more technical in nature and is more about the team working out how the selected backlog items will be delivered.
- However, they should be welcome to attend if they wish, which may help their understanding of what’s involved to deliver the features, and may help if any further clarification is required as the tasks are discussed and estimated.
3. 設定你有多少時間可以花在這個Sprint
(1) Calculate the team’s Sprint Budget: the available number of hours the team has to work on the Sprint.
(The available hours in the Sprint Duration X the number of full-time people in the Sprint )
+ (For people who are working part-time in the Sprint, include the number of hours they can commit to)
- (Any reasonable deductions for time that team members will not be able to spend working on the Sprint)
(2) Deduct holidays, any known meetings, any time likely to be spent working on other projects, etc.
(3) Based on past experience, deduct a reasonable amount of time for support, if appropriate.
(4) Make sure all these calculations are transparent and visible to all.
4. 把需求展開成真正處理的工作項目
(1) Go through each Product Backlog item selected for the Sprint. Break the requirements into tasks.
(2) Tasks may include the traditional steps in a development lifecycle
- For instance: Design, Development, Unit Testing, System Testing, UAT (User Acceptance Testing), Documentation, etc.
(3) Remember, agile software development methods do not exclude these steps. Agile methods just advocate doing the steps feature-by-feature, just in time, instead of in big phases.
(4) Each of these tasks, especially development, may be broken down further.
(5) Include all tasks necessary to make the Product Backlog item 100% complete
(6) Agree as a team on your definition of done, so everyone is aware what will have to be completed and included in the estimates.
(7) State tasks as deliverables, if at all possible.
- Deliverables are more measurable than tasks.
- Instead of describing what you’re going to do, describe what you’re going to deliver.
5. 以小時為單位來評估你的工作項目
(1) Keep tasks small. Estimate all tasks in hours. Estimate each task as a team.
(2) Ask everyone what they think, in order to identify missed tasks, or to identify simpler solutions.
(3) Ideally task estimates should be no more than 1 day.
(4) If an estimate is much larger than this, the requirements should be broken down further so the tasks are smaller.
(5) Keeping tasks small enough to estimate at less than 1 day has some specific benefits.
- Breaking tasks down into very small chunks means they are easier to estimate. The accuracy of your estimating will be improved as a result.
- Tasks less than 1 day are more measurable in the daily Scrum (stand-up meeting). 1 day tasks are either done or they are not.
6. 承諾哪些backlog要在這個sprint中完成
(1) Add up all the task estimates for the selected Product Backlog.
(2) If they are significantly over the team’s Sprint Budget, reduce the number of Product Backlog items selected for the Sprint.
(3) Remember the Product Backlog was in priority order, so if possible it should be the lower item(s) on the backlog that are removed from the Sprint.
(4) The remaining list of estimated Tasks – those tasks needed to complete the selected Product Backlog within the Sprint - is your Sprint Backlog.
(5) The team should commit to delivering the Sprint Backlog.
7. 找出後續要作的工作
(1) Sometimes teams under-commit or over-estimate. Stranger things have happened! :-)
(2) In my experience this is quite common when teams are new to Scrum.
- This can sometimes result in an over-cautious approach to the estimates.
I think it’s because they are unfamiliar with the process and potentially out of their comfort zone initially. They may not have had much experience of estimating in the past.
And they may not have been asked to commit to their own delivery before.
This can sometimes result in an over-cautious(謹慎的) approach to the estimates.
(3) Always include some additional scope in your Sprint Backlog, over and above what you think can be achieved.
- This is important in order to have something ready if the team delivers early, as the Sprint should ideally remain a fixed length.
- Clearly identify these items as Stretch Tasks.
(4) Should never expect Stretch Tasks to be reached.
- No-one should ever be beaten up if Stretch Tasks are never reached.
- And if you do manage to complete any Stretch Tasks, this should be cause for celebration!
