在敏捷開發中, 需求是否要一開始就要齊全呢? 當然不是這樣的, 沒有人能一開始就可寫出所有事情的. 即使你想要這樣做, 所花費的時間可能也會超出你想像的久. 所以在 agile 中, 需求是逐步演進的.
這樣的想法, 我想大多數的人是可以接受的, 但是大家會問那要怎麼做呢? 讓我們一步步道來.
目前分類：User Story (19)
- Aug 20 Wed 2014 07:43
在 agile 中如何逐漸展開需求的內容
- Aug 18 Mon 2014 23:50
撰寫使用者故事常見的問題
使用者故事(User Story) 是敏捷社群用來描述需求的 practice. 它非常容易上手, 但是也容易犯下錯誤, 以下便是常見的問題:
1. 都是使用者
User story 有個範本:
- Apr 17 Thu 2014 06:19
在 product backlog 中要列問題還是解法？
上 CSPO 在練習撰寫使用者故事 (user story) 時, 被老師質疑一個很根本的問題: 你是在思考問題, 還是在思考解法?
當你是 product owner, 你需要撰寫使用者故事, 來描述系統所要提供的功能. 所以你可能會用以下方式來述說:
- Mar 17 Mon 2014 09:14
撰寫 User Story 二三事 - 拆解和關聯性
身為開發人員的我們, 在列 user story 時, 常常會做出功能拆解的事情, 而不是找出一個 end to end, 對使用者有意義, 可以單獨展示的功能.
例如高鐵訂票系統. 當你要訂購一張高鐵票時, 你要選擇要定哪一班, 接著填客戶資料, 然後再輸入付款方式.這些都完成後才能買到票.
- Oct 24 Wed 2012 07:59
User Story Mapping 的介紹
這次在 Agile Meetup 五分鐘分享會要分享的內容, Enjoy it
https://www.facebook.com/AgileCommunity.tw
http://www.slideshare.net/ssusere62027/user-story-mapping-14846349
https://www.facebook.com/AgileCommunity.tw
http://www.slideshare.net/ssusere62027/user-story-mapping-14846349
- Oct 08 Mon 2012 00:17
User Story 的缺點
- Jun 27 Wed 2012 11:31
Gathering User Stories
Gathering User Stories
摘錄至User Stories Applied: For Agile Software Development, 第四章
http://www.slideshare.net/ssusere62027/user-stories-applied-ch4
摘錄至User Stories Applied: For Agile Software Development, 第四章
http://www.slideshare.net/ssusere62027/user-stories-applied-ch4
- Sep 28 Wed 2011 13:57
在撰寫user story時五種常見的錯誤
5 Common Mistakes We Make Writing User Stories
http://www.scrumalliance.org/articles/366--common-mistakes-we-make-writing-user-stories
1. User Story都只有一個 user
- Sep 14 Wed 2011 13:31
常見的User story問題
常見的User story問題
有些時候很多user story, 它們會有共同的task, 例如架構設計, 撰寫測試程式.
有些人會將這些task變成user story. 理由可能如下:
有些時候很多user story, 它們會有共同的task, 例如架構設計, 撰寫測試程式.
有些人會將這些task變成user story. 理由可能如下:
- Sep 27 Mon 2010 14:27
Use Case和User story的差別 - 範例篇
Use Case和User story的差別 - 範例篇
很多人常常會問use case和user story有甚麼差別, 之前在這兩篇中有些解釋
http://www.wretch.cc/blog/kojenchieh/13288119
http://www.wretch.cc/blog/kojenchieh/15451296
今天在San Diego聽老外演講時, 聽到一個範例不錯
1. Feature Sets
- Aug 22 Sun 2010 10:15
切割user story的文章整理
切割user story的文章整理
最近要訂定每個sprint所要產出的內容, 可是發現大家有遇到一些問題
1. 不知道甚麼是sprint的產出要怎麼定
2. 不知道甚麼是user story, 大小要如何, 內容要填寫甚麼
3. 都是以internal module or architecture為導向, 所以產出都是某個module已經完成
- Apr 02 Fri 2010 15:44
Use case 和user story的差別(2)
Use case 和user story的差別(2)
User Stories Applied - for agile software development, Mike Cohn
Chatper 12 What stories are not?
Mike 整理了一些use case和user story的比較. 大家可以參考一下
1. size
Use case 和user story都是要deliver business value. 但是user story比較小, 這是我們有些限制, 像是要寫在便利貼上, 並且要求要來和customer溝通, 因此通常會比use case小
- Mar 29 Mon 2010 22:32
User Stories和Use cases的差別
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/
很多人覺得user story和use case很像, 但是有些地方又感覺不太像. 這篇文章中幫我們說明了她們之間的差別.
首先讓我們先來看一下兩者自己本身的定義:
1. User story
- May 15 Fri 2009 09:24
如何撰寫Non-Functional 需求的User Story
如何撰寫Non-Functional 需求的User Story
Non-functional Requirements as User Stories
http://blog.mountaingoatsoftware.com/non-functional-requirements-as-user-stories
Nov, 21, 2008
Posted by Mkie Cohn
Published in Mike Cohn's Blog
- May 03 Sun 2009 19:20
User Stories 二三事
User Stories 二三事
Extreme Progamming - Installed
Author: Ron Jefries, Ann Anderson, Chet Hendrickson
Translator: 范綱志
Chapter 4 使用者陳述
(1) User Stories是從使用者的觀點出發, 來描述系統行為的簡短敘述
- Feb 20 Fri 2009 09:31
切割User Story
切割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!
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!
- Feb 16 Mon 2009 09:28
Use Cases 和 User Story 不同之處
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真正的需求, 更著重有效溝通. 不知各位看倌你們的感覺如何?
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真正的需求, 更著重有效溝通. 不知各位看倌你們的感覺如何?
- Jan 20 Tue 2009 09:53
什麼一個好的User Story?
什麼一個好的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
- 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
- Jan 19 Mon 2009 10:17
What Is A User Story
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.
- 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.
