在做Scrum Master过程中经常遇到有同学不清楚Jira中的Story; Technical story; Task; Sub-task有什么差别; 也整不明白究竟什么类型的问题应该建Bug，毕竟，Nobody 喜欢自己名下挂Bug。
那这几个事务类型的定义和差别是什么呢？ 具体来说主要是以下差别。
Story：A story is something that brings value to our customer (internal or external)
首先需要说明的是故事什么？为什么要写故事而不是需求文档？故事是收集需求的一种手段，是反映业务需求的一种比较好的手段。故事主要指的是用户故事，能给客户带来价值的事务类型。关键特性在于面向顾客，也就是说Story的出发点是客户要具有业务价值而且要满足INVEST原则。
Independent: 故事是独立的，也就是说一个故事实现的是一个完整独立的功能。
Negotiable: 故事是可协商的，不管是对客户还是对团队，故事并不是一成不变的而是根据实际的情况进行调整。例如，故事超过13点可以进行拆分。
Valuable: 业务语言而不是技术语言，站在用户角度想是有价值的，多问下为什么，为什么想要这样的功能。
Estimate: 故事是可以估算的，也就是说从业务和技术层面来看dev team 都是清楚的，不清楚的东西没有办法估算。估算就是看下这个故事的复杂度是多少。估算过程中团队可以进行充分的交流和沟通，说不定可以提出很多有建设性的意见，最基本的一点就是要认真听需求 ，SM多提问将大家拉到故事上来。估算故事点的价值在于建设性意见，不单是一个简单的点的估算。有了这个点之后也容易追踪团队的速率，有助于将团队的效率可视化，让团队的任务变得可追踪。
Small: 这个小是多小呢？很难把控，但是不让它太大牵涉太多功能，至少保证这个功能在冲刺中是可以完成的。
Testable: 故事的完成一定是经过测试验证的和PO验收的，否则没有质量保障，这也是team 成员之间的相互牵制。
要想故事写的好，模版少不了，下面是User story的一个模版和示例。
Template for User Stories
(see real life examples below)
Goals
As a XXX
I want to XXX
so that XXX
Constraints
xxx
Acceptance criteria
Scenario - xxx
GIVEN xxx
WHEN xxx
THEN xxx
(AND xxx)
Scenario - xxx
GIVEN xxx
(AND xxx)
WHEN xxx
THEN xxx
Out of Scope
xxx
ToDos
UX Screens
Dev input
示例：
Goals
As a customer
I want to call the concierge to request the inspiration I'm looking at
So that I can get more information
Constraints
* temporary solution before we can use the chat channel
Acceptance Criteria
Scenario: show contact option (call only)
GIVEN Doc Brown is interested in Milan Fashion Escape
WHEN he chooses to get detailed information on this inspiration
THEN he will be shown an option to call the concierge
BUT there will be no option to request the inspiration (via chat)
Scenario: initiate call
GIVEN customer Doc Brown is checking out inspiration details for Milan Fashion Escape
WHEN he chooses to call the concierge
THEN a call to the pre-defined concierge phone number will be initiated via the OS-specific phone application
BUT no information will be transmitted to JP that Doc Brown was looking at Milan Fashion Escape
Scenario: back to 360 from the call
GIVEN Doc Brown has been chatting with a JP concierge
WHEN he hangs up the call
THEN he will be back in the 360 app where he left
Out of Scope
* hidden chat message to inform concierge on which experience the customer is looking at
ToDos
UX Screens
Dev input
Task：A task is something that has to be done, not per se technical （本身不是技术性的）
Task 的主要特点在于本身不是技术性的，而且是在冲刺当中必须要做的事情，Task和story是一个等级，Task 下面可以建subtask.
Sub-Task：Represents development tasks to accomplish the user story. (No story point estimates.) Generally no more than 1-day tasks.
subtask 主要指的是为了实现某个用户故事而进行的开发活动，一般建在故事下面且能在一天内完成。
Technical story: represents a set of engineering work that is not directly related to a user story
技术故事代表的是和用户故事不直接相关的一系列的技术工作。
没有例子的解释都是耍流氓，那么为了更加清楚地说明这几个事务类型的差别，请看下方例子。
User Stories:
User Login screen.
Forgot Password workflow.
Lock account after too many failed attempts.
Google login support.
Facebook login support.
Sub-Tasks:
User Login screen:
Design login page.
Cut SVG icons and images.
Implement login page HTML/CSS/JS.
Create SQL scripts to create tables.
Create SQL scripts for stored procedures.
Create web service REST API for user resource.
Hook up login page to web service REST API.
Forgot Password workflow:
...
Technical story:
Setup GitHub project repo.
Setup GCP (or AWS) account, containers, and services.
(There might be Sub-Tasks for these too)
...
Setup Jenkins CI pipeline.
Design overall (high-level) system architecture.
Research and decide on unit test and mocking framework.
那最后一个问题来了，Bug是什么嘞？怎么样优雅地给开发提Bug呢？
Bug： is a problem which impairs or prevents the functions of the product.
Bug 首先是一个问题，而且是影响或阻碍了产品功能的问题。有的小伙伴问了，俺在测试过程中发现有一堆堆问题，能不能都提Bug 给开发呀？当然不能啦，只有阻碍了已有功能的问题才算Bug，如果测试过程中发现有功能根本没做那就不算Bug, 出门右转请找PO去写user story。
那测试又问了怎么样才能提一个优雅的Bug呢？ DUANGDUANGDUANG， 请看下方友情提示。
Bugs should contain subsequent information:
Summary
The goal of summary is to make the report searchable and uniquely identifiable.
A bad example: Drag Crash
A good Example: Drag-selecting any page crashes Mac builds in NSGetFactory
Environment Setup and Configuration
OS, Hardware, etc.
Priority
Indication from the reporter, how fast this bug should be fixed.
This is just an indication, the Rank on the board states the final priority.
Severity
How critical this bug is to the business value.
Example: “Wrong spelling in the H1 heading 'Thes is our website!' on the landing page.”
This bug gets Low Severity because it doesn't influence functionality. Users are still able to do something on this page.
But we should assign High Priority to this bug, because this is a heading – the first thing a user will see when coming to
your website. And there shouldn't be any spelling mistakes.
Affected Version
Use the label field for the affected version.
Overview/Description
Including expected results/behaviour and actual results/behaviour
Steps to Reproduce
Screenshot / Screen Recording
OMG，到这里你已经全部了解了它们的差别，给自己鼓个掌吧。BTW，友情提醒，明天520哟。