User Story

2022/07/11 (增加連結)
2022/10/16 (新增投影片、微調內容)
2025/03/10 (新增投影片)

簡介

User story對敏捷而言是相當重要的實作(practice)，由於敏捷強調需求細節的確認越晚越好，然而，這樣的做法會遇到一個大問題，就是開發者對於整個系統的未來性會很不清楚，透過user story (以及user story mapping)，會了解系統的整體性，在規劃細節時，才能先留下未來擴充的餘地。

一般而言，user story是以使用者的角度與可以理解的方式來寫，而且是簡單的敘述，可以使用「I am, I want, So that」的描述格式，如:「我是個店員，我希望能看到還沒有出貨的消費者訂單，而且訂單最好是依照下單的先後排序，這樣子我可以依照訂貨的先後順序出貨」，這樣的寫法，簡單的定義使用者、所需要的功能以及要提供的價值或可解決的問題。

• The Truth About User Stories

• We need to talk about User Stories. 

• How to write a good user story — a practical approach

  • User Story

  • Background

  • Mockup

  • SBE (Story by example)

  • Acceptance Criteria

• A Guide To Writing Effective User Stories 

• The “Right Way” to Write a User Story 

  • Requirements Methodologies:

    • Behavior Driven Development (BDD)

    • Hypothesis Driven Development (HDD)

• It’s time to start writing useful User Stories!

  • One step at a time

  • Use clear words within the acceptance criteria

  • Don’t forget the invisible part

  • User Stories are written from the user perspective

  • Forcing everything into User Stories (a common mistake)

• Writing Kick-Ass User Stories 

  • D — Description

  • A — Acceptance Criteria

  • R — Refinement

  • E — Estimate

  • S — Split

• What are NOT User Stories? 

  • User Stories are not about writing; they are about building a shared understanding.

  • Requirements

    • We should be curious to understand the users’ perspective. We have to accept we don’t have all answers. We collaborate intensively until we clarify what matters the most.

  • Solutions

    • A good User Story should represent a problem to solve, instead of a solution to deliver.

  • Tasks

    • Agile Development: Difference Between a Story and a Task 

      • A user story is a functionality that will be visible to end-users

      • A task is something like code this, design that, create test data for such-and-such, automate that and is typically done by one person

  • All Product Backlog Items Are User Stories

• Stop creating technical stories 

• What Not to Do With User Stories 

  • User Story is NOT a Solution to Implement

  • Do Not Ignore the Conversation with the Team

  • Don’t Force Everything into User Stories

• User Stories are ill-suited for expressing requirements

  • User Stories are never a work of fiction

    • User Stories work because they tell a factual story about who will be using the product and what they are looking to accomplish together with the expected benefit.

  • User Stories are not requirements vehicles or descriptions of features

    • Splitting an ‘Epic’ User Story into smaller User Stories is often a bad idea. **

  • User Stories are not about what you write down

    • User Stories are not about what you write down but about what is understood.

  • User Stories done right

    • User Stories should be at a high enough level of granularity to depict a real user goal and explain why our users want to attain that goal.

雖然，有人認為user story是由使用者來寫，但是，需求有兩個面向，一個是從使用者觀點來看，由使用者描述希望系統能做些什麼以便達到什麼目的，另一個則是從開發者的角度，分析並統整使用者的需求，並且描述解決方案。所以，越來越多人認為應該由使用者提供或者透過使用者發現要解決的問題或價值，再由開發團隊評估並提出解決方法，再與使用者確認解決方案是否能解決問題或提供所需要的價值。所以，user story最核心的概念是，user story的主角是誰? 要解決的問題或價值? 解決方案是?

• The Most Important Lesson about Software Development from the Past 50 Years 

  • A usage-centric approach to requirements and design will meet customer needs better than a feature-centric approach.

  • I recommend that BAs shift requirements conversations away from the product itself and toward what users need to do with the product. We change the emphasis from functionality to usage, from the solution to the need. 

以前面的例子而言，主角是「我是個店員」，要解決的問題是「可以依照訂貨的先後順序出貨」，解決方案是「希望能看到還沒有出貨的消費者訂單，而且訂單最好是依照下單的先後排序」。

可以使用User story來簡單的陳述使用者的觀點(詳參: 使用者故事 、如何寫出 User Story)，在開發前，再以流程圖(或活動圖)說明user story之間的關係，並以雛形介面或測試案例來做為需求規格 (詳參: 敏捷開發需要哪些文件?)。

• User Stories (1) 什麼是 User Story?

• 編寫使用者故事

• Anatomy of a user story

  • Following the basic format

    • As a <persona> I want <a capability> So that <value>

  • Adding context

    • As a <persona> who <context> I want <a capability> So that <value>

    • When <context> I want <motivation> So that <outcome>

• The Powers of “So-That”​ for Product Managers

  • Power 1: connect outputs to outcomes in user stories.

  • Power 2: connect outcomes to outcomes.

  • Power 3: manage team dependencies

• Moving beyond user story templates 

• A user story is not a template, it’s a process 

另外，User Story必須排優先順序，一般而言，會採用Minimum Viable Product (MVP)原則，MVP原則可以說是「成功達到想要之成果的最小產品釋出」﹐如果不確定甚麼樣的產品會成功，也可以思考「能夠用來證實你的假設的最小產品釋出」 (詳參: MVP 應該是什麼?)，或者如Jeff Patton在書的「請先讀我」章節裡所說的「你的任務不是更迅速地建造更多軟體:而是最大化從你選擇建造的東西中得到的成果與影響」。

Priority

• Staying Focused and Understanding Trade-offs

• Feature Prioritizing: 3 Ways to Reduce Subjectivity and Bias 

  • Overcoming prioritization biases

    • Method 1. Annotated marks

    • Method 2. Descriptive canvas

    • Method 3. Diversified votes

MVP

• How to define a Minimum Viable Product

  • Identify your users

  • Think as a user

  • Think as an entrepreneur

  • Prioritize, Rank, Set the focus

  • Reality check

• Why You Should Build Every New Product Feature Like an MVP

• Should You Build a Minimum Viable Product?

• Before You Launch Your Minimum Viable Product, Do This

  • Make sure everyone is aware of our MVP’s goals.

  • Define success, failure, and what to do when the MVP lands between the two.

  • Test the shit out of it.

  • Bring in friends and family.

  • Make the Call

• The Myth of Minimum Viable Product

  • An MVP needs a small feature set, high quality, low automation, and maximum flexibility. Once these things come together then the only thing stopping us from launch is fear itself.

• Is this a prototype or an MVP? Well actually, it’s a proof of concept

  • In contrast to both POC and Prototypes, the MVP has increased production readiness (exposed to real users/customers), while offering only the right minimum subset of features to keep the users happy and engaged.

• This MVP madness must stop 

  • Start by calling it the ‘Earliest Testable Product’, then the ‘Earliest Usable Product’ and then the ‘Earliest Lovable Product’. 

Card, Conversation, Confirmation

將使用者故事寫在Card上，對話 (Conversation)才是使用者故事成功的關鍵，開發者要透過對話去了解使用者的需求，確認 (Confirmation)是利用Acceptance Criteria來作為完成這個使用者故事的確認標準。(詳參: Essential XP: Card, Conversation, Confirmation)

如Jeff Patton所說的「使用者故事不是需求的書面形式: 利用文字與圖像，透過協同合作述說故事是建立共識的有效機制」以及「使用者故事不是需求: 而是為我們的組織、客戶和使用者解決問題的相關討論，產生關於要建造甚麼的共識」。

• Understanding the three “C”s of agile User Stories 

• Some sketches about using User Stories to facilitate shared understanding: bad, better, best. 

User Story Card

通常使用者故事會寫在一張卡片上，或者，整理成表格，基本上會有這些欄位，就像前面的說明，角色與價值是很重要的，要特別關心價值而不是需求本身。另外，很多專家建議在排進時程時，還沒開發系統前，才去寫接受條件。

• Story name

• As a (角色, who)

• I want (需求, what)

• so that (價值, why)

• Acceptance Criteria (接受條件)

• comment

還可以加上

• user story的類別 (如:user activity, user task, user story) 

• user story的規模

• user story的優先順序

• 情境 (when, where)

• 如何完成 (how)

例如:

• 名稱: 依類別尋找產品

• 類別: User story

• 角色: 身為 購買者

• 需求: 我想要可以 依類別找到產品

• 價值: 因此我可以 找到我想要的產品

• 接受條件: 

  • Scenario: 購買者由類別中尋找產品

    • Given 購買者知道產品的所屬類別

    • When 購買者看到所有的類別後，選擇產品的所屬類別

    • Then 購買者可以看到所有類別中的產品 (品名、金額)

• 優先順序: 1

• 名稱: 看產品詳細資訊

• 類別: User story

• 角色: 身為 購買者

• 需求: 我想要可以 看產品詳細資訊

• 價值: 因此我可以 更瞭解我找到的產品

• 接受條件: 

  • Scenario: 購買者看產品資訊

    • Given 在利用「尋找產品」找到想要的產品之後

    • When 購買者看到產品的資訊，並想要看詳細資訊

    • Then 購買者可以看到產品的詳細資訊 (品名、詳細描述、產品照片、是否有庫存、金額)

• 優先順序: 1

詳參: 

• It’s not my job to write requirements

  • In fact, it’s not the PM’s job to define the solution at all. It’s her job to define the problem and discover solutions alongside the rest of the product team.

• Agile LEGO City workshop: 用樂高積木來模擬敏捷開發的實際情形的一個小遊戲

• Agile Story Card Templates

• User Story Template

• Software Architecture Rule of Thumb — Requirements!

  • Use Testable Acceptance Criteria

• 15 App Ideas to Build and Level Up your Coding Skills (sample user stories)

• 5 ways to get the most out of your user stories

  • User testing

  • Wire framing & Prototyping

  • Development

  • Testing & QA

  • Product Roadmapping and more

• 3 Useful tips to be a Ninja in User Story specifications

  • Create a template

  • Iterate and refine your work

  • Define your ‘Definition of Ready’ criteria

Trello

• Tracking user stories with Trello

• How to set up Trello board for Scrum

  • boards

    • Product Backlog

    • Sprint Planning

    • Current Sprint

    • In Progress

    • Done

  • user story

    • Points

    • Tasks

    • Themes/Epics

    • Story Details

• 可利用Label來設定優先順序

常見的問題

• Five scenarios to avoid while writing User Stories

  • User Stories must have a single purpose (O)

  • Avoid words that do not generate a single understanding (O)

  • ALWAYS refine the User Story with the development team (O)

  • Breaking User Stories in a way that don’t generate value (X)

  • Forcing tasks into User Stories (X)

• 大部分的開發者過去都使用use case，所以，會把兩種的功能混在一起，有些錯誤甚至也是在寫use case時常犯的錯誤。

• 使用者 (F:2)：寫use case時常犯的錯誤

  • 不區分使用者 (A:1) (User Incognito C:2) (D:5) (E:1) (F:2) (G:1)

  • 不是從客戶角度出發 (A:2) (E:2, E:3)

  • 不應該以Product Owner的角度出發 (E:2) (F:2)

  • 不應該以Developer的角度出發 (B:6) (D:3)(E:3)(F:2)

• 沒有商業價值 (A:3) (D:1)(E:4)：use case中會提到目標，但一般比較不強調這一點

  • 忘了寫商業價值 (D:1)

  • 切太細，看不到該使用者故事的價值 (B:1)

    • 以開發者的角度切使用者故事、把開發工作當使用者故事 (B:6) (D:3)

• 驗收條件 (A:4) (B:4) (Criteria Crisis C:5)(E:5)(F:1)(G:4)：use case中驗收會有所謂的Test Case，但通常不會和use case一起完成

  • 沒有驗收條件 (A:4) (B:4) (Criteria Crisis C:5)(E:5)

  • 驗收條件與需求不相符 (F:1)

  • 驗收條件太複雜 (F:1)

• 大小 (G:3)：寫use case時常犯的錯誤

  • 可以採用 User Story Mapping

  • 太大 (B:2) (Disastrous Details C:3) (The Odyssey D:2)

    • 橫跨好幾個Sprint

    • 需求過於複雜

    • 需求異動的機率高

  • 太小

    • 等到要開發的時候，需求已經改變了 (B:3)

    • 寫太細，限制了開發者的空間 (D:4)

• 需求 (F:3)：寫use case時常犯的錯誤

  • 把使用者故事當做規格 (B:5)

    • 忽略與使用者的對話 (溝通) (Story Handoff C:4)(G:6)

  • 太模稜兩可 (F:3)

  • 太複雜 (F:3)

  • 太技術性 (B:6)(C:1)(F:3) (G:5)

• 把我們做事方法的問題歸罪到使用者故事 (B:7)

• 誤用User Story (Story Mania) (C:1)

• 太注重標題 (G:2)

• 沒有公開User Story (G:7)

• 詳參: 

  • 撰寫使用者故事常見的問題 (A)

  • 7 reasons some user stories aren’t useful stories (B)

  • 5 Common User Story Mistakes (C)

  • 5 Classic Mistakes Made While Writing User Stories (D)

  • 5 Common Mistakes We Make Writing User Stories (E)

  • 3 Common User Story Mistakes (F)

  • 7 Common User Story Mistakes and How to Avoid Them? (G)

延伸閱讀

• The Most Important Points Nobody Told You Before You Started Building That App

  • The final product will look nothing like the original specifications

  • The more stakeholders you have on a project, the messier the final result

  • There will always be one part of the finished product that nobody knows exactly what it does

  • One person on your team will be in charge of moving the goalposts

• How to Write Your First Product Requirement Document

  • 內容來自Product requirements documents, downsized

• User Story

  • Agile LEGO City workshop: 用樂高積木來模擬敏捷開發的實際情形的一個小遊戲

  • User Stories by Mike Cohn

  • 使用者故事 User story

  • 如何寫出 User Story

  • 10 TIPS FOR WRITING GOOD USER STORIES

  • 在 agile 中如何逐漸展開需求的內容

  • 撰寫使用者故事常見的問題

  • 撰寫 User Story 二三事 - 拆解和關聯性

  • How (and Why) to Write Great User Stories

    • User stories ≠ tasks

    • Stay high-level

    • Understand the users

    • Think as a user

    • Think big

    • Use epics

    • Don’t discard — prioritize instead

    • Setup for success — not just acceptance

    • Tag stories, add metadata

    • Don’t stick to sticky notes!

    • You still need specs

    • Visualization helps

  • What is a user story? (ELI5)

    • What is a user story?

      • A user story is a short description of functionality told from the user’s perspective.

    • What is an epic?

      • An epic is a super story, and the parent of multiple child user stories

    • Why use user stories? Why not just a task?

      • A user story is the WHAT, the task is the HOW.

    • What are acceptance criteria?

      • Defining conditions for when a user story is done

      • Acceptance criteria is, “did we build the right thing”. Definition of Done is “are we finished building the right thing?”

    •  How to write good user stories?

      • Short, clear language, who is it for, and why do you need it?

    • User story examples

      • Who? > What? > Why?

  • Why user stories are important to developers

  • Bring your users to life with user stories and needs statements

    • needs statements

      • We met…

      • Who needs…

      • Because…

  • How to improve your User Stories and the efficiency of your team

    • Think about the types of users who use your system. You can go the sophisticated way and write personas, or keep it simple and define some roles. Do not use generics like “user”, “developer”, “owner”.

    • Really and honestly ask yourself why the feature is needed. Which goal does the user want to achieve when using this feature? Do not think in implementations (buttons, tables) but in goals instead.

    • Be generic in the “what” part and give the development team some room for creativity. Do not specify details of the user experience or implementation unless they are really important to you for some reason.

  • Writing User Stories, Examples and Templates In Agile Methodologies

  • Agile User Stories and Groomed Product Backlog

  • Use cases vs. user story

    • Use Cases 和 User Story 不同之處

    • User Stories和Use cases的差別

    • Use case 和user story的差別(2)

    • Use Case和User story的差別 - 範例篇

  • Story Splitting Cheat Sheet

  • Vertically splitting stories 

  • The Art of Splitting User Stories 

    • Splitting Method #1 — SPIDR

    • Splitting Method #2 — Story Splitting Flow Chart

  • Three Common Misconceptions About User Stories

    • User Stories Are Part of Scrum

    • User Stories Are Specifications

      • A user story is an invitation to a conversation between user and developer and not a specification. The findings of this conversation are certainly captured, but this documentation is not the story.

    • The Product Owner Writes the User Stories

  • Improvement Stories: a simple alternative to User Stories

    • We have<current situation>, we want to have<desired situation>.

  • No more user stories! There are jobs to be done

    • When, I want to, So I can

• User story & test case

  • YOUR BEST AGILE USER STORY

• Epics are dead. Here’s what we should do instead.

• User story mapping

  • User Story Mapping

  • User story mapping (ppt)

  • User story mapping 使用者故事對照 ( by 中央大學Ruddy Lee)

    • 對付需求模糊的好幫手 – User Story Mapping (1)

    • User Story Mapping – IPO篇:串連使用者故事 (2)

    • 看見的力量 – (III)使用者故事地圖 (3)

    • 需求變化太過頻繁? (4)

    • 敏捷需求的分析工具

  • User Story Mapping Series 

    • How to create a User Story Map

    • How to Prioritize a User Story Map

    • Tips for Facilitating a User Story Mapping Session

    • Don't Etch your User Story Map in Stone

    • Story Maps - A Testing Tool After All

  • User Story Mapping For Beginners

    • STEP 1 – DISCOVERY PHASE – UNDERSTAND THE GOALS

    • STEP 2 – DISCOVERY PHASE – Detail the Journey

    • STEP 3 – DESIGN PHASE – CREATE THE SOLUTION

    • STEP 4 – DEVELOPMENT PHASE – PRIORITIZE TASKS

    • STEP 5 – DEVELOPMENT PHASE – RELEASE

    • STEP 6 – IMPROVE AND REPEAT

• User story mapping tools

  • Top Tools for User Story Mapping: From Post-Its to the Best Digital Apps (2016)

    • headliners

      • StoriesOnBoard (30天免費試用)

      • FeatureMap (Starter for free,  2 maps)

    • potentials

      • Agile User Story Map for JIRA/Atlassian

      • Mural

      • CardBoard

      • RealTimeBoard

  • Useful resources for user story mapping

  • 使用者故事地圖：線上工具介紹

    • CardBoard by DevJam (public for free)

      • Introducing the all new CardBoard

      • 跟Trello很像，不過，比較彈性(可以畫橫分隔)，也可以用在其他用途，如:

        • User Story Map, Opportunity Canvas, Business Model Canvas, Simple Kanban Board

        • NEW UPDATES: Introducing Templates!

      • 跟FeatureMap比起來，功能也比較陽春，不像FeatureMap那樣，可以把下一層的數字加到上一層，不過，比較彈性(可以設定多於三層)

      • Opening Cards in CardBoard

      • Voting in CardBoard!

    • StoriesOnBoard by DevMads

    • FeatureMap by Salience (Starter for free/2 maps)

    • Trello (免費)

    • RealTimeBoard (free for 5 maps)

  • 7 Best Story Mapping Tools for Distributed Agile Teams (2015)

    • JIRA Agile

    • Team Foundation Server

    • BoardThing

    • StoriesOnBoard (30天免費試用)

    • FeatureMap (Starter for free,  2 maps) 

      • 教學 (1:27)

    • Symphonical

    • Trello