David Ko的學習之旅

切割user story的文章整理
最近要訂定每個sprint所要產出的內容, 可是發現大家有遇到一些問題

Use case 和user story的差別(2)
User Stories Applied - for agile software development, Mike Cohn
Chatper 12 What stories are not?

User Stories和Use cases的差別
Requirements 101: User Stories vs. Use Cases
http://www.stellman-greene.com/2009/05/03/requirements-101-user-stories-vs-use-cases/

如何撰寫Non-Functional 需求的User Story
Non-functional Requirements as User Stories
http://blog.mountaingoatsoftware.com/non-functional-requirements-as-user-stories

User Stories 二三事
Extreme Progamming - Installed
Author: Ron Jefries, Ann Anderson, Chet Hendrickson
Translator: 范綱志
Chapter 4 使用者陳述

切割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.

Use Cases 和 User Story 不同之處

Use cases - User Stories: so precious but not the same !
http://www.agile-ux.com/2009/01/23/use-cases-user-stories-so-precious-but-not-the-same/

以前在做object oriented/UML 時, 談的都是user cases, 現在在做agile時, 開始改談user story.

可是一開始覺得user story的描述和user case很像, 只是user story長了一點. 然後user story也不會像user case一樣要寫, scenario, pre-condition, post-condition...等等.

總覺得兩者, 說像不像, 總是同中有異.

在網路上找到有人比較兩者之間的差異, 讓我們一起來看看有什麼不同:

1. A user story is a brief description of functionality as viewed by the user (Role → Goal).
- It doesn’t model the interaction between the actor and the system, what the use case does.
- A user story is not a sequence of actions.

2. A user story is short and consist in one or two sentences written in the language of the user
- Example: As a recruiter, I can submit job vacancies. A role and a goal, then it is discussed.
- A use case is heavier, richer in information: goal, summary, actor, precondition, trigger event, main success scenario and extensions (alternative paths, errors …). Use case is (too much) detailed.

3. A user story is smaller and can finally be seen as a part of a specific use case: the main success scenario or an extension

4. User stories are used for planning.
- They play a major role in project estimation and planning (via story points and velocity).
- Use cases are not used for planning, even if you can use “use cases points” technique to estimate project size.

5. User stories emerge faster than use cases; use cases require more time for analysis and writing

6. User stories are more readable than use cases
- Use cases usually belong to a large word document, often poorly written and difficult to read even in a structured template

7. User stories are easier to maintain than a 150 pages Use cases Document

8. User stories are based on verbal communication and rely on collaboration, discussion and proximity to clarify details
- Use case is a textual model (associated with diagrams): every thing is written !

9. User stories are in theory written on cards
- Remember the 3 C rule: Card, Conversation, Confirmation
- They’re not intended to be archived unlike use cases.

10. A user story must be implemented and tested in one iteration
- A specific use case can be implemented in several iterations: main success scenarion on iteration 1; extensions in Iteration 2 and 3 …

11. User stories can be more easily written by a user or customer
- Most of the time use cases are written by user proxies (BA, Consultants …)

12. User stories contain acceptance tests (validation criteria) written on the back of the story card; use case not: tests cases are created in a separate documentation

13. Use cases provide a more holistic view of the system: precondition, UC diagram, sub use case. Linking user stories is less obvious. This is also a reason why UX and IxD activities are so important in agile contexts !

14. Finally, Use cases and user stories are usually associated with two different methodologies (Unified Process vs eXtreme Programming).
- But you can do user stories in a Unified Process environment !

作者雖然已經有十年使用use case經驗, 但是現在他覺得user story是他的最愛, 原因呢?
* User stories focus on what is really important
* User stories are more appropriate for collaboration
* User stories can perfectly be combined with UX(User eXperience) activities (Personas, Storyboard, Wireframes):
  User stories + UX artifacts = Just enough

看起來user story是比use case, 更有效率想要找出user真正的需求, 更著重有效溝通. 不知各位看倌你們的感覺如何?

什麼一個好的User Story?
- form User Stories Applied: For Agile Software Development

好的User Story會具備哪些要素:
- Independent
- Negotiable
- Valuable to users or customers
- Estimatable
- Small
- Testable

Independent
(1) Avoid making dependencies between stories
- Hard to prioritize and plan
(2) Instead,
- Combine dependent stories
    If the combined story is longer, it is usually to find a different dimension along which to split the stories
- Split in another way
(3) Example
- 你可能會寫出這樣的user story
    A company can pay for a job posting with a Visa card.
    A company can pay for a job posting with a MasterCard.
    A company can pay for a job posting with an American Express card.
- 改成這樣會比較好
    A company can pay for a job posting with a credit card
    
Negotiable
(1) User stories are not written contracts
- Story cards are short descriptions of functionality
- The details are to be negotiated in a conversation between the customer and the development team
(2) Consider them placeholders/reminders for a conversation you should have
(3) Consider what is the right amount of information written in a user story
(4) Details that have already been determined through conversations become tests.
- Tests can be noted on the back of the story card or
- in whatever electronic system is being used
(5) Example:

Valuable to users or customers
(1) Stories with value for the user is a given
(2) Remember stories for the customer
(3) Avoid stories that have only value for the developers
- Rewrite them so they have value for the customer
(4) The best way is to have the customer write the stories.
- Ensure that each story is valuable to the customer or users
(5) Keeping in mind the distinction between user and purchaser
- These stories might be only valued by purchasers
    Throughout the development process, the development team will produce documentation suitable for an ISO 9001 audit.
    The development team will produce the software in accordance with CMM Level 3.
- These stories might be only valued by users
    Each of the 5,000 computers is using the same configuration for the software.
(6) Find business values, not technology and the advantages to the programmers
- Examples:
    All connections to the database are through a connection pool.
    All error handling and logging is done through a set of common classes.
- Better examples:
    Up to fifty users should be able to use the application with a five-user database license.
    All errors are presented to the user and logged in a consistent manner.

Estimatable
(1) Without estimates, no plan
(2) Typical reasons why a story is hard to estimate
- Developers lack domain knowledge
- Developers lack technical knowledge
- The story is to big

Small
(1) Size matters
- Wrong size makes planning hard
(2) No definitive answer to size
(3) Faced with too large a user story see if it is
- A compound story
- A complex story
(4) A compound story
- Epic that comprises multiple shorter stories
- What does the user story: “A user can post her resume” mean ?
    It should be split
- But not to small…
- CRUD operations can work as guidelines
(5) A complex story
- Cannot easily be disaggregated
- Stories are often complex because of uncertainty
- Split in two stories
    An investigation store
    A development story

Testable
(1) Stories must be written so as to be testable.
- Successfully passing its tests proves that a story has been successfully developed.
(2) If a story cannot be tested, how can we know when we are done coding ?
(3) Un-testable stories commonly show up for nonfunctional requirements
(4) If possible, make test automated

What Is A User Story
- form User Stories Applied: For Agile Software Development

最近team要開始採用user story 的方法, 因此需要花一些時 間來研究, 要如何套用會比較合宜. 我基本上相信, 要套用一個新的aprroach, 應該是花時間熟悉它是什麼, 和想辦法試試看是否能原汁原味的採用.

公司之前有很多team 在採用一些新的methodology, 大多是採用一個, 就怨恨一個, 常常會認為那方法不適合在這個地方執行. 可是在我看來, 你既沒花時間研究它, 也沒有心要要全面使用它, 或是套用他所有規則, 自然就不會成功.

就像Agile來說, 大家只知道要做iteration, 可是卻沒有採用要達成iteration, 所要使用相關的practices. 因此run下來, 大家只是很累地快速deliver了幾個版本, 可是是否快速反應user需求, 或是仍能維持適當的品質水準, 這些事情反而變成不是大家討論的重點.

有鑒於這些教訓, 小弟想想還是要花時間研究一下, 希望自己在run 完後, 也不會一直怨恨.

首先, 就先開始拜讀User Stories Applied: For Agile Software Development 一書, 從了解什麼是User Story開始.

What Is A User Story
1. Describes functionality that will be valuable to either a user or purchaser of a system
2. Example
    - A user can search for jobs.
    - A company can post new job openings.
    - A user can limit who can see her resume.
3. Not good examples
    - The software will be written in C++.
    - The program will connect to the database through a connection pool.
    
Three Aspects of A User Story
1. A "Written Description" of the story used for planning and as a reminder
2. "Conversations" about the story that serve to flesh out the details of the story
3. "Tests" that convey and document details and that can be used to determine when a story is complete

Written description
1. Short heading, typically one or two lines
2. Often written on an index card
3. Used throughout the project for
    - Planning
    - Reminder

Conversations
1. Used to uncover the details of the story
2. Takes place throughout the project, e.g.,
    - When estimating the story
    - When implementing the story
3. Notes from these conversations can be added to the index card
    - the conversation is the key, not the note on the story card.
    
Tests
1. Specify and describe details about a story as tests, e.g., some of the details uncovered during the conversation
2. Use the tests to determine when a user story is complete, i.e., acceptance tests
3. Write the tests on the back of the index card

Big User Story
1. It is better to have more stories than to have stories that are too large.
2. Epics (Big user stories) can be split into two or more stories of smaller size
3. We do not continue splitting stories until we have a story that covers every last detail.
    - We stop when it is a very reasonable and realistic story
4. Rather than writing all these details as stories, the better approach is for the development team and the customer to discuss these details.