You might want to think of your story as a vertical slice of the system. A story may (and often will) touch components in all of the architectural layers of the system. You might therefore want to think of your tasks as the work needed to be done on each of the components that your story touches.
For example, Let's say you have a story like In order to easily be able to follow my friends' tweets, as a registered user, I want to automatically follow all of my gmail contacts that have twitter accounts.
In order to accomplish this, you will have to pass through the UI layer, service layer, persist some data in the data layer, and make an API call to twitter and gmail.
Your tasks might be:
Add an option to the menu
Add a new gmail authentication screen
Add a twitter authentication screen
Add a contact selection screen
Add a controller that calls into your service layer
Write a new service that does the work
Save contacts to the database
Modify your existing gmail API calling service to get contacts
Add a twitter API calling service to follow selected contacts
There: That's 9 possible tasks right there. Now, as a rule, you want your tasks to take roughly 1/2 a day to 2 days, with a bias towards one day (best practice, for sizing). Depending on the difficulty, you might break down these tasks further, or combine some if they are two easy (perhaps the two API calling services are so simple, you'd just have a modify external API services).
At any rate, this is a raw sketch of how to break the stories down.
EDIT:
In response to more question that I got on the subject of breaking stories into tasks, I wrote a blog post about it, and would like to share it here. I've elaborated on the steps needed to break the story. The link is here.
When we started projects under a Scrum management style, the first set of tasks was always broad, or as you describe it: epic. That's inevitable, the framework of any project is usually the most important, largest, and time-consuming portion, but it supports the rest of the project. In order to pare down the scale on overwhelming-ness of how much there is to do see if you can list the MOST essential parts. Then work on defining those tasks as the starting points. Therefore you have a few tasks as starting points for a broad beginning. Hope that makes sense!
A user story describe the what while a task is more about the how.
There is no perfect formula, just add any task that describe how the user story is going to be implemented, documented or tested.
Keep in mind that a task should be estimated in hours, so try to scale and detail the tasks accordingly.
If you feel that you have too many tasks for a story (even if you have 1-8 hours long tasks), then maybe you should consider rewriting your user story in the first place because it's probably too complex.
The story that you implement at the beginning can be refined over time. You dont need to think that every story has to be the final version that the user is going to use.
For example, in a recent project we had to develop an application which involved indexing various websites, and matching them against filters created by users, and finally alerting the user of matches (thing of it as google alert on steroids).
If you look at it from one perspective, there is only one story - "As a user I want to get alerts from matching pages". But look at it from another perspective of "what are the risks we want to mitigate". The first risk was that users wouldn't get relevant or better hits compared to google alerts. The second risk was in learning the technology to build this.
So our first user story was simply "As a user I want relevant hits", then we built just the hit matching algorithm on a hardcoded set of pages and hardcoded filters for some early users and got their feedback.
There might actually be a bit of back and forth here with multiple smaller stories to capture learning like "As a user I want more priority to be given to matches in the URL" etc.. these stories comes from the feedback as we iterate over what the early users consider "relevant hits".
Next, we broadened it to "As a user I want hits from specific websites" and we built the indexing architecture to crawl user specified sites and do hit matching on that.
The third story was "As a user I want to define my own filters", and we built this part of the system.
In this way we were able to build up the architecture piece by piece. Through most of the initial part, only early users could use the system, and many pieces of data were hardcoded etc.
After a point, early users could use the system completely. Then we added stories for allowing new users to register and opened it up to the public.
To cut a long story short, the story you implement first could implement only a small part of the final story, hardcoding and scaffolding everything else. And then you can iterate on it over time till you get the story that you might actually release to the public.
I've come to a crossroads with this issue in the past. User stories are supposed to be isolated so you can do them without any other stories, in whatever order, etc. But I found making that happen just made everything more complicated. To me this fell under the "Individuals and interactions over processes and tools" part of the agile manifesto - or at least my interpretation of it.
The ultimate goal is ship. And to ship you have to build, and to build you have to stop futzing with scrum and just get stuff done and make sure you track it.
So what we did was break a cardinal rule of stories and we made some tech stories like "create a preliminary schema". We also declared that some stories were dependent on others, and noted that on the back of the story card.
In the end I felt this type of story was few and far between, and the difficulty of the alternative justified the exception.
发布评论
评论（5）
您可能希望将您的故事视为系统的垂直部分。一个故事可能（并且经常会）涉及系统所有架构层中的组件。因此，您可能希望将您的任务视为在您的故事涉及的每个组件上需要完成的工作。
例如，假设您有一个类似的故事作为注册用户，为了能够轻松关注我朋友的推文，我希望自动关注拥有 Twitter 帐户的所有 Gmail 联系人。
为了实现这一点，你必须穿过 UI 层、服务层，在数据层中保存一些数据，并对 twitter 和 gmail 进行 API 调用。
您的任务可能是：
这里：那里有 9 个可能的任务。现在，作为一项规则，您希望任务每天花费大约 1/2 到 2 天的时间，偏向于一天（最佳实践，用于调整规模）。根据难度，您可能会进一步分解这些任务，或者如果它们是两个简单的任务，则将它们组合起来（也许这两个 API 调用服务非常简单，您只需修改外部 API 服务） 。
无论如何，这是如何分解故事的原始草图。
编辑：
为了回答我收到的有关将故事分解为任务的更多问题，我写了一篇关于它的博客文章，并想在这里分享。我已经详细阐述了打破这个故事所需的步骤。链接位于此处。
You might want to think of your story as a vertical slice of the system. A story may (and often will) touch components in all of the architectural layers of the system. You might therefore want to think of your tasks as the work needed to be done on each of the components that your story touches.
For example, Let's say you have a story like In order to easily be able to follow my friends' tweets, as a registered user, I want to automatically follow all of my gmail contacts that have twitter accounts.
In order to accomplish this, you will have to pass through the UI layer, service layer, persist some data in the data layer, and make an API call to twitter and gmail.
Your tasks might be:
There: That's 9 possible tasks right there. Now, as a rule, you want your tasks to take roughly 1/2 a day to 2 days, with a bias towards one day (best practice, for sizing). Depending on the difficulty, you might break down these tasks further, or combine some if they are two easy (perhaps the two API calling services are so simple, you'd just have a modify external API services).
At any rate, this is a raw sketch of how to break the stories down.
EDIT:
In response to more question that I got on the subject of breaking stories into tasks, I wrote a blog post about it, and would like to share it here. I've elaborated on the steps needed to break the story. The link is here.
当我们在 Scrum 管理风格下启动项目时，第一组任务总是很广泛，或者正如您所描述的：史诗般的。这是不可避免的，任何项目的框架通常是最重要、最大、最耗时的部分，但它支持项目的其余部分。为了缩小需要做的事情的规模，看看你是否可以列出最重要的部分。然后将这些任务定义为起点。因此，您有一些任务作为广泛开始的起点。希望这是有道理的！
When we started projects under a Scrum management style, the first set of tasks was always broad, or as you describe it: epic. That's inevitable, the framework of any project is usually the most important, largest, and time-consuming portion, but it supports the rest of the project. In order to pare down the scale on overwhelming-ness of how much there is to do see if you can list the MOST essential parts. Then work on defining those tasks as the starting points. Therefore you have a few tasks as starting points for a broad beginning. Hope that makes sense!
用户故事描述了
内容，而任务更多的是关于如何。如果您觉得一个故事的任务太多（即使您有 1-8 小时长的任务），那么也许您应该首先考虑重写您的用户故事，因为它可能太复杂了。
祝你好运
A user story describe the
whatwhile a task is more about thehow.howthe user story is going to be implemented, documented or tested.If you feel that you have too many tasks for a story (even if you have 1-8 hours long tasks), then maybe you should consider rewriting your user story in the first place because it's probably too complex.
Good luck
您一开始实施的故事可以随着时间的推移而完善。您不需要认为每个故事都必须是用户将使用的最终版本。
例如，在最近的一个项目中，我们必须开发一个应用程序，其中涉及对各种网站进行索引，并将它们与用户创建的过滤器进行匹配，最后向用户发出匹配提醒（就像类固醇上的谷歌警报一样）。
如果你从一个角度来看，只有一个故事——“作为一名用户，我希望从匹配的页面获得提醒”。但从“我们想要降低哪些风险”的另一个角度来看。第一个风险是，与谷歌提醒相比，用户不会获得相关或更好的点击。第二个风险是学习构建它的技术。
因此，我们的第一个用户故事只是“作为用户，我想要相关的点击”，然后我们在一组硬编码的页面和硬编码的过滤器上为一些早期用户构建了点击匹配算法，并获得了他们的反馈。
实际上，这里可能有一些来回的情况，有多个较小的故事来捕获学习，例如“作为用户，我希望对 URL 中的匹配给予更多优先级”等。这些故事来自我们迭代内容时的反馈。早期用户考虑“相关点击”。
接下来，我们将其扩展为“作为用户，我希望来自特定网站的点击”，并且我们构建了索引架构来抓取用户指定的网站并对其进行点击匹配。
第三个故事是“作为用户，我想定义自己的过滤器”，我们构建了系统的这一部分。
通过这种方式，我们能够一点一点地构建架构。在初始部分的大部分时间里，只有早期用户才能使用该系统，并且许多数据都被硬编码等。
过了一个点，早期用户就可以完全使用该系统了。然后我们添加了允许新用户注册的故事并向公众开放。
长话短说，您首先实现的故事只能实现最终故事的一小部分，对其他所有内容进行硬编码和搭建。然后你可以随着时间的推移迭代它，直到你得到你可能真正向公众发布的故事。
The story that you implement at the beginning can be refined over time. You dont need to think that every story has to be the final version that the user is going to use.
For example, in a recent project we had to develop an application which involved indexing various websites, and matching them against filters created by users, and finally alerting the user of matches (thing of it as google alert on steroids).
If you look at it from one perspective, there is only one story - "As a user I want to get alerts from matching pages". But look at it from another perspective of "what are the risks we want to mitigate". The first risk was that users wouldn't get relevant or better hits compared to google alerts. The second risk was in learning the technology to build this.
So our first user story was simply "As a user I want relevant hits", then we built just the hit matching algorithm on a hardcoded set of pages and hardcoded filters for some early users and got their feedback.
There might actually be a bit of back and forth here with multiple smaller stories to capture learning like "As a user I want more priority to be given to matches in the URL" etc.. these stories comes from the feedback as we iterate over what the early users consider "relevant hits".
Next, we broadened it to "As a user I want hits from specific websites" and we built the indexing architecture to crawl user specified sites and do hit matching on that.
The third story was "As a user I want to define my own filters", and we built this part of the system.
In this way we were able to build up the architecture piece by piece. Through most of the initial part, only early users could use the system, and many pieces of data were hardcoded etc.
After a point, early users could use the system completely. Then we added stories for allowing new users to register and opened it up to the public.
To cut a long story short, the story you implement first could implement only a small part of the final story, hardcoding and scaffolding everything else. And then you can iterate on it over time till you get the story that you might actually release to the public.
我过去曾遇到过这个问题的十字路口。用户故事应该是孤立的，这样你就可以在没有任何其他故事的情况下以任何顺序等完成它们。但我发现这样做只会让一切变得更加复杂。对我来说，这属于敏捷宣言中“个体和交互高于流程和工具”的一部分——或者至少是我对它的解释。
最终目标是船。为了交付，你必须构建，而为了构建，你必须停止使用 Scrum，只管完成工作并确保跟踪它。
因此，我们所做的就是打破故事的基本规则，我们制作了一些技术故事，例如“创建初步模式”。我们还声明某些故事依赖于其他故事，并在故事卡的背面注明。
最后我觉得这种类型的故事很少见，而替代方案的难度证明了例外是合理的。
I've come to a crossroads with this issue in the past. User stories are supposed to be isolated so you can do them without any other stories, in whatever order, etc. But I found making that happen just made everything more complicated. To me this fell under the "Individuals and interactions over processes and tools" part of the agile manifesto - or at least my interpretation of it.
The ultimate goal is ship. And to ship you have to build, and to build you have to stop futzing with scrum and just get stuff done and make sure you track it.
So what we did was break a cardinal rule of stories and we made some tech stories like "create a preliminary schema". We also declared that some stories were dependent on others, and noted that on the back of the story card.
In the end I felt this type of story was few and far between, and the difficulty of the alternative justified the exception.