如何進行Sprint Planning (上)
How To Implement Scrum In 10 Easy Steps - Step #3: Sprint Planning (Requirements)
http://www.agile-software-development.com/2007/10/how-to-implement-scrum-in-10-easy-steps.html
Sprint planning meeting 對scrum來說是非常重要的一個步驟, 如果在一開始沒有先講清楚, 讓大家有一致的共識, 之後在這一個sprint就會很混亂.
因為他們會不知道要做的東西到底是什麼 ? 要做到怎樣才夠?因為在這短短的sprint中, 時間是很有限, 要做的東西應該是要十分清楚的.
1. 進行 Sprint Planning Workshop
(1) Make sure the meeting is attended by the whole team.
(2) Include all roles.
(3) The first thing you must do (in your first Sprint Planning meeting) is decide on your Sprint duration. This decision should be taken as a team.
2. 決定sprint的長度
(1) Scrum suggests 30 days.
(2) The optimum Sprint duration depends on many factors.
(3) A development team's 'cycle time' is a direct reflection of the maturity of their processes.
- A team with immature processes will find the intensity of Scrum and the overhead of Sprint Planning, Testing, Deployment and Review quite onerous for a short Sprint cycle.
- Whereas teams with very mature processes (for example automated testing, automated deployment, and teams who've become very quick at Sprint Planning), a short cycle might be very comfortable.
(4) Mike Cohn is one of the key exponents of agile development.
- See here for Mike's article giving further advice about how to select the optimum iteration length.
http://www.mountaingoatsoftware.com/article/view/30
3. 保持所有sprint的長度是一致的
(1) Whatever Sprint duration you choose to go for, my advice is to keep it consistent.
(2) Allows you to get into a rhythm.
(3) Makes your process very repeatable.
(4) Allows you to start understanding how many Product Backlog points you can typically do in a Sprint.
(5) Once you've decided, you can now set up a Sprint Planning Workshop as a recurring appointment before every Sprint.
4. 選擇這個sprint想要的backlog
(1) Looking at the top section of the Product Backlog,
- What would seem to be a reasonable goal to set for the Sprint?
- Can you express an objective that sums up the goal for the next Sprint, or
- At least pick a section of items/features from the top of the Product Backlog that the team thinks can be achieved in the Sprint duration?
(2) Select your target backlog for the Sprint. Make this decision as a team.
(3) It's important to prepare more items during planning in case the team finishes early.
- These items can be clearly identified as stretch tasks and the Product Owner should not expect them to be completed.
(4) In future Sprints, you will be able to use your Scrum team's previous Velocity to help with this decision.
- Velocity is the number of Product Backlog Points delivered in a Sprint.
- This tends to fluctuate wildly early on when adopting Scrum.
- But it will settle down as the team get into a rythm, and in future provide you with a reasonable norm to base your target backlog on.
5. 釐清sprint的需求
(1) Take each item on the Product Backlog. It's important to go through them methodically, one item at a time...
(2) The Product Owner presents each item and explains how he/she sees it working from a functional perspective.
(3) The whole team discusses the item in detail.
- The whole team asks questions about the feature in order to establish what it should do and how it should work.
- The outcomes of this discussion should be captured on a whiteboard or flipchart, or someone could write notes on a laptop as the discussion progresses.
(4) Write requirements in a way that is lightweight and visual.
- Agile requirements should be barely sufficient.
- The fact the features will be developed and tested within the next few weeks, and by the team that were present, makes this possible.
(5) Consider writing 'User Stories'.
- But the basic concept is to write features using this construct:
As a [type of user], I want to [do whatever], so I can [achieve what goal].
- The story can be backed up by a sketch of the UI, a wireframe or visuals.
- Annotate the sketch to describe the functionality.
- Backed it up with statements about how it will be confirmed (or tested).
- This will help to identify scenarios up front, before it's developed.
How To Implement Scrum In 10 Easy Steps - Step #3: Sprint Planning (Requirements)
http://www.agile-software-development.com/2007/10/how-to-implement-scrum-in-10-easy-steps.html
Sprint planning meeting 對scrum來說是非常重要的一個步驟, 如果在一開始沒有先講清楚, 讓大家有一致的共識, 之後在這一個sprint就會很混亂.
因為他們會不知道要做的東西到底是什麼 ? 要做到怎樣才夠?因為在這短短的sprint中, 時間是很有限, 要做的東西應該是要十分清楚的.
1. 進行 Sprint Planning Workshop
(1) Make sure the meeting is attended by the whole team.
(2) Include all roles.
(3) The first thing you must do (in your first Sprint Planning meeting) is decide on your Sprint duration. This decision should be taken as a team.
2. 決定sprint的長度
(1) Scrum suggests 30 days.
(2) The optimum Sprint duration depends on many factors.
(3) A development team's 'cycle time' is a direct reflection of the maturity of their processes.
- A team with immature processes will find the intensity of Scrum and the overhead of Sprint Planning, Testing, Deployment and Review quite onerous for a short Sprint cycle.
- Whereas teams with very mature processes (for example automated testing, automated deployment, and teams who've become very quick at Sprint Planning), a short cycle might be very comfortable.
(4) Mike Cohn is one of the key exponents of agile development.
- See here for Mike's article giving further advice about how to select the optimum iteration length.
http://www.mountaingoatsoftware.com/article/view/30
3. 保持所有sprint的長度是一致的
(1) Whatever Sprint duration you choose to go for, my advice is to keep it consistent.
(2) Allows you to get into a rhythm.
(3) Makes your process very repeatable.
(4) Allows you to start understanding how many Product Backlog points you can typically do in a Sprint.
(5) Once you've decided, you can now set up a Sprint Planning Workshop as a recurring appointment before every Sprint.
4. 選擇這個sprint想要的backlog
(1) Looking at the top section of the Product Backlog,
- What would seem to be a reasonable goal to set for the Sprint?
- Can you express an objective that sums up the goal for the next Sprint, or
- At least pick a section of items/features from the top of the Product Backlog that the team thinks can be achieved in the Sprint duration?
(2) Select your target backlog for the Sprint. Make this decision as a team.
(3) It's important to prepare more items during planning in case the team finishes early.
- These items can be clearly identified as stretch tasks and the Product Owner should not expect them to be completed.
(4) In future Sprints, you will be able to use your Scrum team's previous Velocity to help with this decision.
- Velocity is the number of Product Backlog Points delivered in a Sprint.
- This tends to fluctuate wildly early on when adopting Scrum.
- But it will settle down as the team get into a rythm, and in future provide you with a reasonable norm to base your target backlog on.
5. 釐清sprint的需求
(1) Take each item on the Product Backlog. It's important to go through them methodically, one item at a time...
(2) The Product Owner presents each item and explains how he/she sees it working from a functional perspective.
(3) The whole team discusses the item in detail.
- The whole team asks questions about the feature in order to establish what it should do and how it should work.
- The outcomes of this discussion should be captured on a whiteboard or flipchart, or someone could write notes on a laptop as the discussion progresses.
(4) Write requirements in a way that is lightweight and visual.
- Agile requirements should be barely sufficient.
- The fact the features will be developed and tested within the next few weeks, and by the team that were present, makes this possible.
(5) Consider writing 'User Stories'.
- But the basic concept is to write features using this construct:
As a [type of user], I want to [do whatever], so I can [achieve what goal].
- The story can be backed up by a sketch of the UI, a wireframe or visuals.
- Annotate the sketch to describe the functionality.
- Backed it up with statements about how it will be confirmed (or tested).
- This will help to identify scenarios up front, before it's developed.
全站熱搜
留言列表
