切割User Story
User Story Splitting
http://www.scrumlabs.com/2008/11/user-story-splitting/
理想狀況下, 每個user story需要在一個sprint內做完. 因為Scrum強調working software, 他希望在每次sprint完後, 可以看到一個可以運作的軟體出現. 若是user story太大或是因為某種原因無法在一個sprint內完成, 就會失去working software的精神.
但是事實上, 在很多狀況下, 有些user story是無法在一個sprint中完成. 那要怎麼辦呢?
首先, 作者認為分割 user story是其中一種方法. 而哪些user story要被分割呢? 以下狀況的user story, 作者認為是不錯的選擇
* When the user story is an Epic - and therefore too large to fit within a Sprint
* When part of the user story cannot be estimated, or is too difficult to estimate
* When part of the user story has a higher priority than the remainder
* When part of the user story is riskier than the remainder
找到要分割的user story之後, 那要怎麼切割呢? 作者認為, 若是像他技術背景出身的人, 很容易考量以Architecture or Component Centric來做切割. 但是作者也明白指出, 這樣做並不一定是最佳的方法, 因為從使用者的角度來看, 這樣並沒有提供出好的business value
所以作者提供以下幾種角度, 去考量如何切割user story
1. Roles
- Sometimes a user story is written with a single role shown
- But on further investigation it appears that the user story can be split up into multiple roles and therefore multiple user stories.
- I have seen this on multiple occasions so it is often a quick win to identify user stories exhibiting this characteristic and to break them down according to roles.
2 Transactional
- E.g. a user story that combines all activities together might be able to broken down on a transaction basis
* e.g. Transactions to Create Customer Details, then Read Customer Details,
then Amend Customer Details,
then Delete Customer Details.
- Having written the Create transaction before you write the Read Transaction etc is not always the most desired way but often is.
3. Understood verses Non Understood
- When the team has a tough time trying to understand one part of the User Story
- But you need to see progress, then one option is to split out what you understand as one user story from the less understood element as a second user story
- Have a task associated with the less understood element to understand it!
- Sometimes this is called a Spike.
4. High value verses low value elements within the user story
- May be able to be split out delivering much desired business value earlier.
5. Architectural boundaries
- Often the least preferred method
- But sometimes supported with the argument that building on architectural lines is the most optimum way of doing things.
- The question is – optimum for whom – the Architect or the Business?
6. And then there is this: Twenty Ways to Split Stories
- http://xp123.com/xplor/xp0512/index.shtml
which provides further alternatives that will help you brainstorm other alternatives.
User Story Splitting
http://www.scrumlabs.com/2008/11/user-story-splitting/
理想狀況下, 每個user story需要在一個sprint內做完. 因為Scrum強調working software, 他希望在每次sprint完後, 可以看到一個可以運作的軟體出現. 若是user story太大或是因為某種原因無法在一個sprint內完成, 就會失去working software的精神.
但是事實上, 在很多狀況下, 有些user story是無法在一個sprint中完成. 那要怎麼辦呢?
首先, 作者認為分割 user story是其中一種方法. 而哪些user story要被分割呢? 以下狀況的user story, 作者認為是不錯的選擇
* When the user story is an Epic - and therefore too large to fit within a Sprint
* When part of the user story cannot be estimated, or is too difficult to estimate
* When part of the user story has a higher priority than the remainder
* When part of the user story is riskier than the remainder
找到要分割的user story之後, 那要怎麼切割呢? 作者認為, 若是像他技術背景出身的人, 很容易考量以Architecture or Component Centric來做切割. 但是作者也明白指出, 這樣做並不一定是最佳的方法, 因為從使用者的角度來看, 這樣並沒有提供出好的business value
所以作者提供以下幾種角度, 去考量如何切割user story
1. Roles
- Sometimes a user story is written with a single role shown
- But on further investigation it appears that the user story can be split up into multiple roles and therefore multiple user stories.
- I have seen this on multiple occasions so it is often a quick win to identify user stories exhibiting this characteristic and to break them down according to roles.
2 Transactional
- E.g. a user story that combines all activities together might be able to broken down on a transaction basis
* e.g. Transactions to Create Customer Details, then Read Customer Details,
then Amend Customer Details,
then Delete Customer Details.
- Having written the Create transaction before you write the Read Transaction etc is not always the most desired way but often is.
3. Understood verses Non Understood
- When the team has a tough time trying to understand one part of the User Story
- But you need to see progress, then one option is to split out what you understand as one user story from the less understood element as a second user story
- Have a task associated with the less understood element to understand it!
- Sometimes this is called a Spike.
4. High value verses low value elements within the user story
- May be able to be split out delivering much desired business value earlier.
5. Architectural boundaries
- Often the least preferred method
- But sometimes supported with the argument that building on architectural lines is the most optimum way of doing things.
- The question is – optimum for whom – the Architect or the Business?
6. And then there is this: Twenty Ways to Split Stories
- http://xp123.com/xplor/xp0512/index.shtml
which provides further alternatives that will help you brainstorm other alternatives.
全站熱搜
留言列表
