I agree with pma_. Do what makes sense. In this case, you have some great looking user stories.
"As an editor, I would like to get notified when an article has been submitted so that I can review it."
If you have a ton of these, then perhaps they are too small. They would all be 1-2hrs. That's probably not a good thing to have. In that case, try grouping them. Perhaps "As an editor, I want to be able to manage articles". That would include several of the ones you have already.
Keep in mind the goals of user stories...
Track items on a burndown chart
Deliver fully functional work (not an unusable subset of work)
Have estimatable portions
If you can achieve those goals, you're good. If not, try again.
Oh, and one last thing - keep the flow diagram, don't throw it out in favor of stories. But supplement the stories with it.
If this business workflow is like most business workflows, each of those steps will have a significant number of rules. Those rules should map into acceptance criteria for those stories and ideally, automated tests to prove that the code works as intended. Because of the potential for a lot of acceptance criteria, I would lean towards the second option.
I tend to go towards Features/Epics early on with the core end user/stakeholder value-adding functionality, such as in your example to "Publish an article so that the subscribers can get the latest news". Then once the Feature is getting closer to implementation I'll split it into implementation sized stories if needed.
Most non-trivial business workflows benefit from being split up during implementation so that they can be continiously deployed and verified in order to get early feedback from the stakeholders. The big con of having everything as one big bang implementation is late validation. I think that having early feedback is outweighing the increased administrative burden of handling multiple stories.
A tip on how to split epics into stories: Lasse Koskela has a great writeup on how to split stories in different ways.
We're currently building a business process based content management system. We split our processes into stories as per your 2nd option.
But, of course, we keep the flow diagram handy. In fact, we print it out and stick it to the wall. We even keep every old version of it so we've our own paper based version control stuck to our wall (in addition to using git for the electronic version ;-) )
希望这是有道理的。我建议任何想担任 PO 角色的人阅读 Mike Cohn 的《敏捷估算和规划》。祝你好运！
In Scrum however, it is advised for requirements to be in the form of user stories. What is the best way to approach this?
The two options that you have mentioned are not really options, they are sequential stages, IMHO. During Agile Requirements Gathering or Product Planning the first step is to create EPIC stories. After you have those Epics, you need to break them down into smaller chunks.
Without the EPICs you will most likely to run into the issue of creating random stories without getting a grasp on the sense of belonging of a story. You can in a way create a hierarchy in User Stories. Without understanding that, everything is just random, hence it makes it tougher to wrap your head around or manage the stories as a PO.
Offcourse there is much more to all this than what I mentioned in the above paragraph. That's why probably you need an experienced Scrum Coach or do a lot of diligent reading/implementing on Agile Planning and User Story writing.
Hope this makes sense. I would suggest reading Agile Estimating and Planning by Mike Cohn for anyone who even remotely thinks of taking up a PO role. Best of Luck!
Workflows are an interesting entry to writing user stories and epics, but user stories don't map to work flows, they map to business capabilities. So you are incorporating some fallacious thinking from the start in this question. Workflows are a good tool for the conversation, but will live independently of workflow as they are about functionality, not timing. Timing lives in the business rules. On that note, business rules are not Acceptance Criteria, they are the connection between Acceptance Criteria, which are features that can be demonstrated by a product owner, and Test Cases. Again, Acceptance Criteria are about features, not behavior. Behavior lives in the business rules. For instance I might have User Story for an ATM that says "As a user, I can check my account balance." And the Acceptance Criteria could be "If I am overdrafted, I get an alert notice." The rules for what constitutes an over draft (I had $1000 in my account and deposited my $2500 pay check, but that won't clear before my $1500 mortgage payment, etc.) are not acceptance criteria. They are business rules whose execution results in the demonstrable action of the Acceptance Criteria. Note, that this user story could be captured through a workflow analysis, but might live in many workflows (or none).
发布评论
评论（7）
我同意pma_。做有意义的事。在这种情况下，您有一些很棒的用户故事。
“作为一名编辑，我希望在文章提交时收到通知，以便我可以对其进行审阅。”
如果你有很多这样的东西，那么它们可能太小了。他们都是1-2小时。这可能不是一件好事。在这种情况下，请尝试将它们分组。也许
“作为一名编辑，我希望能够管理文章”。这将包括您已经拥有的几个。
记住用户故事的目标...
如果您可以实现这些目标，那么您就很好。如果没有，请再试一次。
哦，还有最后一件事——保留流程图，不要为了故事而把它扔掉。但用它来补充故事。
I agree with pma_. Do what makes sense. In this case, you have some great looking user stories.
"As an editor, I would like to get notified when an article has been submitted so that I can review it."
If you have a ton of these, then perhaps they are too small. They would all be 1-2hrs. That's probably not a good thing to have. In that case, try grouping them. Perhaps
"As an editor, I want to be able to manage articles". That would include several of the ones you have already.
Keep in mind the goals of user stories...
If you can achieve those goals, you're good. If not, try again.
Oh, and one last thing - keep the flow diagram, don't throw it out in favor of stories. But supplement the stories with it.
如果此业务工作流程与大多数业务工作流程类似，那么每个步骤都将具有大量规则。这些规则应该映射到这些故事的验收标准，理想情况下，自动化测试可以证明代码按预期工作。由于可能有很多接受标准，我倾向于第二种选择。
If this business workflow is like most business workflows, each of those steps will have a significant number of rules. Those rules should map into acceptance criteria for those stories and ideally, automated tests to prove that the code works as intended. Because of the potential for a lot of acceptance criteria, I would lean towards the second option.
我倾向于尽早使用核心最终用户/利益相关者增值功能来实现功能/史诗，例如在您的示例中“发布文章，以便订阅者可以获得最新新闻”。然后，一旦该功能接近实现，如果需要，我会将其分成实现大小的故事。
大多数重要的业务工作流程都受益于在实施过程中的拆分，以便可以持续部署和验证它们，以便尽早获得利益相关者的反馈。将所有内容作为一个大爆炸实现的最大缺点是延迟验证。我认为尽早获得反馈比处理多个故事所增加的管理负担更重要。
关于如何将史诗拆分为故事的提示：Lasse Koskela 有 一篇很棒的文章 关于如何以不同的方式分割故事。
I tend to go towards Features/Epics early on with the core end user/stakeholder value-adding functionality, such as in your example to "Publish an article so that the subscribers can get the latest news". Then once the Feature is getting closer to implementation I'll split it into implementation sized stories if needed.
Most non-trivial business workflows benefit from being split up during implementation so that they can be continiously deployed and verified in order to get early feedback from the stakeholders. The big con of having everything as one big bang implementation is late validation. I think that having early feedback is outweighing the increased administrative burden of handling multiple stories.
A tip on how to split epics into stories: Lasse Koskela has a great writeup on how to split stories in different ways.
对我来说，所有敏捷都是关于运用常识。在这种情况下，你有完美的设计，所以只需实现一个，不要寻找不必要的东西。
For me all agile is about using common sense. I this case you have perfect desing so just implement one and don't look for unecessary things.
我们目前正在构建一个基于业务流程的内容管理系统。我们根据您的第二个选项将流程分成故事。
但是，当然，我们将流程图放在手边。事实上，我们将其打印出来并贴在墙上。我们甚至保留了它的每个旧版本，这样我们就可以将自己的基于纸质的版本控制贴在墙上（除了使用 git 作为电子版本之外;-)）
We're currently building a business process based content management system. We split our processes into stories as per your 2nd option.
But, of course, we keep the flow diagram handy. In fact, we print it out and stick it to the wall. We even keep every old version of it so we've our own paper based version control stuck to our wall (in addition to using git for the electronic version ;-) )
您提到的两个选项并不是真正的选项，它们是连续的阶段，恕我直言。在敏捷需求收集或产品规划期间，第一步是创建 EPIC 故事。有了这些史诗之后，您需要将它们分解成更小的块。
如果没有 EPIC，您很可能会遇到创建随机故事而无法掌握故事归属感的问题。您可以通过某种方式在用户故事中创建层次结构。如果不了解这一点，一切都是随机的，因此作为 PO 就更难集中注意力或管理故事。
当然，这一切比我在上一段中提到的内容要多得多。这就是为什么您可能需要一位经验丰富的 Scrum 教练或进行大量关于敏捷规划和用户故事编写的勤奋阅读/实施。
希望这是有道理的。我建议任何想担任 PO 角色的人阅读 Mike Cohn 的《敏捷估算和规划》。祝你好运！
The two options that you have mentioned are not really options, they are sequential stages, IMHO. During Agile Requirements Gathering or Product Planning the first step is to create EPIC stories. After you have those Epics, you need to break them down into smaller chunks.
Without the EPICs you will most likely to run into the issue of creating random stories without getting a grasp on the sense of belonging of a story. You can in a way create a hierarchy in User Stories. Without understanding that, everything is just random, hence it makes it tougher to wrap your head around or manage the stories as a PO.
Offcourse there is much more to all this than what I mentioned in the above paragraph. That's why probably you need an experienced Scrum Coach or do a lot of diligent reading/implementing on Agile Planning and User Story writing.
Hope this makes sense. I would suggest reading Agile Estimating and Planning by Mike Cohn for anyone who even remotely thinks of taking up a PO role. Best of Luck!
工作流是编写用户故事和史诗的一个有趣的入口，但用户故事并不映射到工作流，而是映射到业务功能。所以你从一开始就在这个问题中融入了一些错误的想法。工作流程是一个很好的对话工具，但将独立于工作流程，因为它们与功能有关，而不是与时间有关。时机取决于业务规则。
需要注意的是，业务规则不是验收标准，它们是验收标准（产品所有者可以演示的功能）和测试用例之间的联系。再次强调，验收标准是关于功能，而不是行为。行为存在于业务规则中。
例如，我可能有一个 ATM 机的用户故事，上面写着“作为用户，我可以检查我的帐户余额”。接受标准可以是“如果我透支，我会收到警报通知”。构成透支的规则（我的账户中有 1000 美元，存入了 2500 美元的工资支票，但在我支付 1500 美元的抵押贷款之前不会结清，等等）不是接受标准。它们是业务规则，其执行会导致验收标准的可证明的操作。请注意，该用户故事可以通过工作流分析来捕获，但可能存在于许多工作流中（或没有）。
Workflows are an interesting entry to writing user stories and epics, but user stories don't map to work flows, they map to business capabilities. So you are incorporating some fallacious thinking from the start in this question. Workflows are a good tool for the conversation, but will live independently of workflow as they are about functionality, not timing. Timing lives in the business rules.
On that note, business rules are not Acceptance Criteria, they are the connection between Acceptance Criteria, which are features that can be demonstrated by a product owner, and Test Cases. Again, Acceptance Criteria are about features, not behavior. Behavior lives in the business rules.
For instance I might have User Story for an ATM that says "As a user, I can check my account balance." And the Acceptance Criteria could be "If I am overdrafted, I get an alert notice." The rules for what constitutes an over draft (I had $1000 in my account and deposited my $2500 pay check, but that won't clear before my $1500 mortgage payment, etc.) are not acceptance criteria. They are business rules whose execution results in the demonstrable action of the Acceptance Criteria. Note, that this user story could be captured through a workflow analysis, but might live in many workflows (or none).