User stories and a lot of negotiation over what's essential and what's fluff.
A lot of negotiation.
Also a lot of back-and-forth on architecture. Scrum requires a stable, proven architecture. However, there are always upgrades and enhancements. How do those fit with the backlog? That's a lot of political jockeying between product owner, technology folks and (to an extent) users/buyers.
The process in inherently non-linear.
It's more like crystallization. You have a solution, you start to write stories, you have a technology vision, you have a team with certain skills and experience.
Any one of these features can serve as a "nucleus" for deciding what goes into the backlog and in what order. Eventually, something becomes the nucleus and the mixture crystallizes. Sometimes the cost or schedule or risks are unacceptable, so you heat it back up, find another nucleus and see if it crystallizes acceptably around that new nucleus.
The recrystallization happens after each sprint, by the way, making it even less linear.
Edit. "stable proven architecture".
Question: Who pays for learning the new architecture?
Answer: Ha ha. There's no good answer. So be careful how much architectural learning you do while you have development sprints going on.
If you don't have an architecture in place that (a) works, and (b) can be articulated by almost everyone on the team, you're going to spend time assembling that architecture.
What does the time and cost of creating an architecture do to your first sprint?
You have to incorporate architecture development into the first sprint, delaying things.
Let's say you decide to implement a LAMP stack. You don't know whether to unix PHP, Perl or Python. So you pick one. Like Python. And you promise the first sprint in four weeks. So you work for 3 weeks struggling with the kabillion add-one modules and frameworks. After 3 weeks, you think you have a working tech stack, but you don't have the promised sprint.
Do you delay? If so, everyone asks if you've got the pace right and starts doubling the time for all other sprints.
Do you deliver nothing? If so, what's the point of sprints if you have nothing at the end except infrastructure?
You can change, modify and enhance the infrastructure -- in manageable pieces. But to build a fresh architecture, prove out the pieces, train everyone and develop best practices takes time. A lot of it. And that time shouldn't -- really -- be charged as sprint time creating deliverable product. That's overhead time.
Edit. Tooling.
Rule 1. Agile processes don't use a lot of complex tools and processes. That's why I said that the process is a lot of "negotiation". Whatever makes you productive.
Rule 2. Don't over think it. Just do it.
Most folks say -- in the strongest possible way -- use 5"x8" paper cards and stick them to a wall. Seriously. No tools. Just simple paper, markers, tape and blank wall space.
You can use a spreadsheet to collect user stories (and epics -- stories that have to be decomposed). You can add columns for complexity (story points), cost, priority and release, and use it for project management.
We use use cases (not user stories) but the tooling is the same. A use case is -- in a way -- a user story with more details up front. But the use case name can summarize how an actor interacts with a system; the interaction can usually be summarized with clear, simple nouns and a verb, which is very much like a user story.
Spreadsheets seem handy because you can rearrange the rows at the end of each sprint. You can do simple counts and sums to work out how much each feature will cost and when they'll arrive.
I don't use a spreadsheet because -- in spite of the GUI glitziness -- I find it a little bit cumbersome. I would feel it necessary to write a spreadsheet extractor that would turn the backlog from an Open Office Org file into ReStructuredText (RST). I prefer RST -- plain text markup -- over spreadsheets.
This is all protracted negotiation. Everything changes as a result of every conversation. That's the point of an Agile method. Quick sprint followed by negotiation over the direction of the next sprint.
Our backlog is a big RST document. We publish all our documentation using Sphinx and it's very, very simple to write backlog, use cases, architecture, design, etc., in RST markup.
Our sprints are simply sections of a big document tree. They're decorated with a few special-purpose interpreted text fields for the subjective things like estimated completion date, and status (in process, released).
What comes between the vision (solution to the problem) and the product backlog.
Nothing. From the Vision, you just create the Product Backlog (PB). Note that the Product Backlog Items (PBI) don't need to be all fine grained, only the most emergent items need to. So, don't hesitate to create coarse grained items at the start, you'll decompoose them into fine grained PBI "just in time" (this activity is known as backlog grooming).
With these 2 artifacts, you can start your project. As Ken Schwaber puts it: "The minimum plan necessary to start a Scrum project consists of a vision and a Product Backlog. The vision describes why the project is being undertaken and what the desired end state is." (Schwaber 2004, p. 68)
From what I read, I think it is user stories but I am not sure.
To be honest, I'm not sure that I'm following you here. The PB is by definition a list of PBIs and creating the PB thus means feeding it with PBIs. Now, User Stories are just one possible formalism for the PBIs (Scrum doesn't force you to use User Stories, they are not appropriate for all projects) so, if you decide to use this formalism, creating the PB will mean creating User Stories.
Is there anything online that shows all the steps in a linear fashion from vision/concept to the end?
Below, one of the oldest illustration of the Scrum framework:
You can start by breaking the vision down into a series of epics. These can then live in your backlog as a prioritised list of the "big rocks" of work that need to get donw.
As you start planning each sprint (or a little before), you can break down the epics into user stories and prioritise them.
Google 'user story mapping'. This is a great way to understand a problem from a functional/feature view, and it's the technique I recommend to people who want to build a product but don't know where to start. The input is the vision statement and the output is a prioritized product backlog, plus the model itself.
发布评论
评论（5）
用户故事以及关于什么是必要的、什么是无用的大量谈判。
很多谈判。
还有很多关于架构的反复讨论。 Scrum 需要稳定、经过验证的架构。然而，总是有升级和增强。这些如何与积压工作相适应？产品所有者、技术人员和（在某种程度上）用户/买家之间存在大量的政治角力。
该过程本质上是非线性的。
它更像是结晶。你有了一个解决方案，你开始写故事，你有一个技术愿景，你有一个具有一定技能和经验的团队。
这些功能中的任何一项都可以充当“核心”，用于决定待办事项中的内容和顺序。最终，某些东西成为核心并且混合物结晶。有时成本、进度或风险是不可接受的，所以你将其重新加热，找到另一个核，看看它是否在新核周围结晶得可接受。
顺便说一下，每次冲刺之后都会发生重结晶，这使得它的线性度更低。
编辑。 “经过验证的稳定架构”。
问题：谁为学习新架构付费？
回答：哈哈。没有好的答案。因此，在进行开发冲刺时要小心您进行了多少架构学习。
如果您没有一个能够满足以下条件的架构：(a) 可以工作，并且 (b) 团队中的几乎每个人都可以清晰地表达出来，那么您将花费时间来组装该架构。
创建架构的时间和成本对您的第一个冲刺有什么影响？
你必须将架构开发纳入第一个冲刺，从而延迟事情。
假设您决定实施 LAMP 堆栈。您不知道应该使用 unix PHP、Perl 还是 Python。所以你选一个。就像Python一样。并且您承诺在四个星期内进行第一次冲刺。因此，您花了 3 周的时间与数以十亿计的附加模块和框架作斗争。 3 周后，您认为自己已经有了一个可行的技术堆栈，但并没有实现承诺的冲刺。
你拖延吗？如果是这样，每个人都会问你的配速是否正确，并开始将所有其他冲刺的时间加倍。
你什么都不送吗？如果是这样，如果最终除了基础设施之外什么都没有，那么冲刺还有什么意义呢？
您可以以可管理的方式更改、修改和增强基础架构。但要构建一个新的架构、验证各个部分、培训每个人并开发最佳实践需要时间。很多。实际上，这段时间不应该被计为创建可交付产品的冲刺时间。那是开销时间。
编辑。工装。
规则 1. 敏捷流程不使用大量复杂的工具和流程。这就是为什么我说这个过程是很多“谈判”的原因。任何能让你富有成效的事情。
规则2：不要想太多。去做就对了。
大多数人都会说——以最强烈的方式——使用 5 英寸 x 8 英寸的纸卡并将它们贴在墙上。严重地。没有工具。只需简单的纸张、记号笔、胶带和空白的墙壁空间。
阅读此内容：http://www.agilemodeling.com/artifacts/userStory.htm
您可以使用电子表格来收集用户故事（以及史诗——必须分解的故事）。您可以添加复杂性（故事点）、成本、优先级和发布列，并将其用于项目管理。
我们使用用例（不是用户故事），但工具是相同的。在某种程度上，用例是一个预先包含更多细节的用户故事。但用例名称可以概括参与者如何与系统交互；交互通常可以用清晰、简单的名词和动词来概括，这非常像用户故事。
电子表格看起来很方便，因为您可以在每个冲刺结束时重新排列行。您可以进行简单的计数和求和，以计算出每个功能的成本以及它们何时到达。
我不使用电子表格，因为尽管 GUI 很华丽，但我发现它有点麻烦。我觉得有必要编写一个电子表格提取器，将积压的工作从 Open Office Org 文件转换为 ReStructuredText (RST)。与电子表格相比，我更喜欢 RST（纯文本标记）。
这都是旷日持久的谈判。每一次谈话都会改变一切。这就是敏捷方法的要点。快速冲刺，然后协商下一个冲刺的方向。
我们的待办事项是一份很大的 RST 文档。我们使用 Sphinx 发布所有文档，编写待办事项、用例、架构、设计、等等，在 RST 标记中。
我们的冲刺只是大文档树的一部分。它们装饰有一些特殊用途的解释文本字段，用于主观事物，例如估计完成日期和状态（正在进行中、已发布）。
User stories and a lot of negotiation over what's essential and what's fluff.
A lot of negotiation.
Also a lot of back-and-forth on architecture. Scrum requires a stable, proven architecture. However, there are always upgrades and enhancements. How do those fit with the backlog? That's a lot of political jockeying between product owner, technology folks and (to an extent) users/buyers.
The process in inherently non-linear.
It's more like crystallization. You have a solution, you start to write stories, you have a technology vision, you have a team with certain skills and experience.
Any one of these features can serve as a "nucleus" for deciding what goes into the backlog and in what order. Eventually, something becomes the nucleus and the mixture crystallizes. Sometimes the cost or schedule or risks are unacceptable, so you heat it back up, find another nucleus and see if it crystallizes acceptably around that new nucleus.
The recrystallization happens after each sprint, by the way, making it even less linear.
Edit. "stable proven architecture".
Question: Who pays for learning the new architecture?
Answer: Ha ha. There's no good answer. So be careful how much architectural learning you do while you have development sprints going on.
If you don't have an architecture in place that (a) works, and (b) can be articulated by almost everyone on the team, you're going to spend time assembling that architecture.
What does the time and cost of creating an architecture do to your first sprint?
You have to incorporate architecture development into the first sprint, delaying things.
Let's say you decide to implement a LAMP stack. You don't know whether to unix PHP, Perl or Python. So you pick one. Like Python. And you promise the first sprint in four weeks. So you work for 3 weeks struggling with the kabillion add-one modules and frameworks. After 3 weeks, you think you have a working tech stack, but you don't have the promised sprint.
Do you delay? If so, everyone asks if you've got the pace right and starts doubling the time for all other sprints.
Do you deliver nothing? If so, what's the point of sprints if you have nothing at the end except infrastructure?
You can change, modify and enhance the infrastructure -- in manageable pieces. But to build a fresh architecture, prove out the pieces, train everyone and develop best practices takes time. A lot of it. And that time shouldn't -- really -- be charged as sprint time creating deliverable product. That's overhead time.
Edit. Tooling.
Rule 1. Agile processes don't use a lot of complex tools and processes. That's why I said that the process is a lot of "negotiation". Whatever makes you productive.
Rule 2. Don't over think it. Just do it.
Most folks say -- in the strongest possible way -- use 5"x8" paper cards and stick them to a wall. Seriously. No tools. Just simple paper, markers, tape and blank wall space.
Read this: http://www.agilemodeling.com/artifacts/userStory.htm
You can use a spreadsheet to collect user stories (and epics -- stories that have to be decomposed). You can add columns for complexity (story points), cost, priority and release, and use it for project management.
We use use cases (not user stories) but the tooling is the same. A use case is -- in a way -- a user story with more details up front. But the use case name can summarize how an actor interacts with a system; the interaction can usually be summarized with clear, simple nouns and a verb, which is very much like a user story.
Spreadsheets seem handy because you can rearrange the rows at the end of each sprint. You can do simple counts and sums to work out how much each feature will cost and when they'll arrive.
I don't use a spreadsheet because -- in spite of the GUI glitziness -- I find it a little bit cumbersome. I would feel it necessary to write a spreadsheet extractor that would turn the backlog from an Open Office Org file into ReStructuredText (RST). I prefer RST -- plain text markup -- over spreadsheets.
This is all protracted negotiation. Everything changes as a result of every conversation. That's the point of an Agile method. Quick sprint followed by negotiation over the direction of the next sprint.
Our backlog is a big RST document. We publish all our documentation using Sphinx and it's very, very simple to write backlog, use cases, architecture, design, etc., in RST markup.
Our sprints are simply sections of a big document tree. They're decorated with a few special-purpose interpreted text fields for the subjective things like estimated completion date, and status (in process, released).
没有什么。根据愿景，您只需创建产品待办事项列表 (PB)。请注意，产品待办事项 (PBI) 不需要全部细粒度，只有最紧急的项目才需要。因此，不要犹豫，一开始就创建粗粒度的项目，您将“及时”将它们分解为细粒度的 PBI（此活动称为 待办事项整理）。
有了这 2 个工件，您就可以开始您的项目了。正如 Ken Schwaber 所说：“启动 Scrum 项目所需的最低计划包括愿景和产品待办事项列表。愿景描述了项目实施的原因以及期望的最终状态。” （Schwaber 2004，第 68 页）
老实说，我不确定我是否在跟踪你。根据定义，PB 是 PBI 列表，因此创建 PB 意味着为其提供 PBI。现在，用户故事只是 PBI 的一种可能的形式（Scrum 不会强迫您使用用户故事，它们并不适合所有项目），因此，如果您决定使用这种形式，创建 PB 将意味着创建用户故事。
下面是 Scrum 框架最古老的插图之一：
这是我的建议。如果您需要示例，也许可以看看 Henrik Kniberg 的 索引卡生成器。更多模板和/或示例位于 Scrum 待办事项模板和示例 。
Nothing. From the Vision, you just create the Product Backlog (PB). Note that the Product Backlog Items (PBI) don't need to be all fine grained, only the most emergent items need to. So, don't hesitate to create coarse grained items at the start, you'll decompoose them into fine grained PBI "just in time" (this activity is known as backlog grooming).
With these 2 artifacts, you can start your project. As Ken Schwaber puts it: "The minimum plan necessary to start a Scrum project consists of a vision and a Product Backlog. The vision describes why the project is being undertaken and what the desired end state is." (Schwaber 2004, p. 68)
To be honest, I'm not sure that I'm following you here. The PB is by definition a list of PBIs and creating the PB thus means feeding it with PBIs. Now, User Stories are just one possible formalism for the PBIs (Scrum doesn't force you to use User Stories, they are not appropriate for all projects) so, if you decide to use this formalism, creating the PB will mean creating User Stories.
Below, one of the oldest illustration of the Scrum framework:
This would be my recommendation. If you need a sample, maybe have a look at Henrik Kniberg's Index Card Generator. More templates and/or samples at Scrum backlog templates and examples.
待办事项是在需求定义之后出现的。积压工作处于不断变化的状态，但最终它是有待完成的工作。
这是一个图表：链接
The backlog comes after the requirements are defined. The backlog is in a constant state of flux, but ultimately it is the work left to be completed.
Here is a chart: link
您可以首先将愿景分解为一系列史诗。然后，这些可以作为需要完成的“大石头”工作的优先列表存在于您的积压工作中。
当您开始规划每个冲刺（或稍早）时，您可以将史诗分解为用户故事并确定它们的优先级。
You can start by breaking the vision down into a series of epics. These can then live in your backlog as a prioritised list of the "big rocks" of work that need to get donw.
As you start planning each sprint (or a little before), you can break down the epics into user stories and prioritise them.
谷歌“用户故事映射”。这是从功能/特性的角度理解问题的好方法，也是我向那些想要构建产品但不知道从哪里开始的人推荐的技术。输入是愿景声明，输出是优先的产品待办事项列表以及模型本身。
Google 'user story mapping'. This is a great way to understand a problem from a functional/feature view, and it's the technique I recommend to people who want to build a product but don't know where to start. The input is the vision statement and the output is a prioritized product backlog, plus the model itself.