Job Story目的

Job Story用来表示干系人需要完成的工作，这项工作将被作为product backlog item或者需求。

Job Story描述

关注干系人的动机，并且想要为干系人的动机、焦虑、痛点等提供尽可能多的上下文。

这些上下文可以帮助我们理解干系人的诉求，帮助我们做出正确的实现决策。

Job Story同样可以作为与干系人沟通的工具，用来促进各个角色/干系人之间的互动与协作。

它可以帮助我们交付团队将注意力放在干系人的需求上，而不是陷入实现的细节讨论。

也就是说，先弄清楚客户痛在哪里，解决好WHY的问题，延迟对于HOW的思考。

格式

Job Story 和User Story一样，有着自己独特的格式。

我们可以用第一人称或者第三人称的方式来进行Job Story的书写。

具体格式为：

第一人称

When <situation> 

I want to <motivation> 

so I can <expected outcomes>

第三人称

When someone <situation>, 

actor(s)<motivation> 

so that <expected outcomes>

举个栗子

When我想要从自己的账户中取款时，

I want to知道我的账户里有足够的余额，

so I can和我的朋友一起出去吃饭了。

When someone想要从自己的账户中取款时，

the customer 想要知道是否有足够的余额，the teller想要知道该账户是否是本银行的，

so that 提款人可以取到所需的现金。

Situation

Job Story的第一个元素是：situation情境

情境提供了任务何时需要完成的上下文信息。

交付团队可以基于情境的上下文信息考虑各种可能的解决方案。提供的上下文信息越丰富，交付团队就能设计出来更加符合需求的解决方案。

当有多个角色参与到该任务的完成时，这些角色将被包含在When语句中。

Motivation

Job Story的第二个元素是：motivation动机

动机关注的是目的，可以分为内部动机和外部动机。

值得注意的是，期望的功能或者解决方案不会包括在Job Story中，免得太早的陷入细节而忽视什么是用户想要做什么。

这个是用来回答用户想要做什么。

Expected Outcomes

Job Story的第三个元素是：expected outcomes期待结果

有的小伙伴分不清动机和期待结果这俩元素有什么区别。

动机回答的是WHAT，期待结果回答的是WHY。

比如，我想要看看我钱包里有多少钱（动机），以便于挑个我可以负担得起的馆子请朋友吃饭（期待结果）。

Job Story的优势

不区分角色，消除对于角色的偏见

增加了情景的描述，可以丰富更多的上下文信息

侧重于干系人的动机和目的，而不是过早的定义如何实现

有助于用户体验设计

让团队更容易与干系人产生共鸣

团队可以在backlog上同时使用Job Story和User Story

这里想要说明一下Job Story和User Story。

其实这俩是可以配合使用的，并不是说一定要取谁舍谁。

我们回归一下本质，user story和job story都是为了更好的理解需求和用户的痛点，为了能够让我们的解决方案和交付更有价值。所以不管是哪个story只是侧重点和关注点稍有不同，目的是一致的。我们其实可以明显的看出来，针对于细分用户进行story描述的时候用user story可能会更加明确。

但是在对某种特别的情景下进行story描述的时候用job story会更加合适。

我们写story，refine story，plan story……通常泛指user story，但是在需要的时候我们也可以使用job story。

两相结合，能抓住老鼠的就是好猫。

Job Story使用限制

由于所包含的上下文、角色和结果，这种格式往往比用户故事更冗长

有的时候上下文信息比较复杂，想要用一句话说明白比较难，而且拆分的难度也比较大，在这种情况下Job Story就会比较冗长。

对了，在这里说明一下Job Story也是可以拆分的，拆分的方式和方法可以参考user story的。

对于拆分的场景需要进行优先级的管理

当同时使用user story和job story的时候可能会让团队confuse

我个人觉得不论是什么工具和方法，我们要明确自己的目的，不要陷入格式和规范中。

能让我们的工作事半功倍，让我们的沟通更有效率才是有效的工具使用方式。