items on the current sprint backlog should be approached in priority order, and one item at a time by the whole team.
I don't know who says this, I at least don't remember having heard or read anything like the emphasized text so far. Of course, it depends also on whether an item for you is a story or a single task.
If it's a story (usually consisting of several tasks), there might be a chance of achieving this. However, as you say, sometimes the story just doesn't include enough tasks to keep everyone busy. Also often the tasks related to a story strongly depend on each other, e.g. there might be a design session (involving part or whole of team), then one or more coding tasks, then code review, functional testing, documentation etc. Obviously one can't do functional testing before the coding, and so on.
Since everyone has to do something, there will be at least as many tasks open at any given time as there are team members (or pairs). Taking into account that sometimes tasks are on hold for various reasons (inter-task dependencies, information needed from external parties etc.), usually even more.
In one Scrum project with a team of 4 developers, we had a very similar situation. We did strive to take stories in priority order as much as possible, and usually we had multiple stories and several tasks open at any time. In the beginning we often had problems with several half-finished stories at the end of the sprint. So we realized it is important to keep the number of open tasks / stories to a minimum, i.e. always attempt to finish open tasks /stories first before starting a new one. But practically, that minimum was never meant to be 1.
As for the number of stories per sprint, we just put in as many as we could comfortably fit in based on our (story, then task level) estimations. That was of course greatly influenced by our velocity, which in the beginning was estimated too high. After a couple of months we chipped it down to 60%, and that value seemed to work for us.
The advice to approach each item by the whole team is there to avoid creating mini-waterfalls within sprints, where items are passed from one specialized group to another. That leads to stuff like testers having nothing to do in first days of the sprint, then working overtime for the last couple of days when coders fiddle their thumbs. Teams should approach the problem as a whole with everyone chipping in, even outside of their respective "specialization". Yes, coders can test, testers can code and both can design architectures etc. - and in the process learn something new (amazing). That is not to say everyone should be very good at everything - it is just to say attitude like "I don't test, I'm a coder" or "I won't write this script, I'm a tester" should have no place in a Scrum team.
It is also advised to tackle items one by one inside of sprint to make sure something is actually delivered at the end. Limiting work in progress (WIP) prevents situation, where everyone did some tasks on each item, but no item has been completed by sprint's end.
However, this shouldn't be viewed as advice, not a very strict rule. For example when you have two small stories and a team of 10 it probably doesn't make sense to have all of the team swarm on just one story.
Bottom line is: no one should tell the team how to divide work among themselves, but delivering what they committed to at Sprint Planning should be expected.
I think it depends on the makeup of your team. If you have a team where anyone can take on any given task within a user story, then this works well. If you do not, then there will likely be idle time for some individuals.
The point in working the user stories based on priority is simple... you get the highest priority user story completed first. This adds the most value from the perspective of the customer who actually set the priority.
As for how many user stories to commit to during a sprint, that depends on a few factors: Team Availability, Team Velocity, and Sprint Duration. So, I'm not sure how much value you will get out of knowing how many stories other people tackle during a sprint.
发布评论
评论（4）
我不知道是谁说的，至少我不记得到目前为止听过或读过类似强调文本的内容。当然，这还取决于您的项目是一个故事还是单个任务。
如果这是一个故事（通常由多个任务组成），则可能有机会实现这一目标。然而，正如你所说，有时故事并没有包含足够的任务来让每个人都忙起来。通常，与一个故事相关的任务彼此强烈依赖，例如，可能会有一个设计会议（涉及部分或整个团队），然后是一个或多个编码任务，然后是代码审查、功能测试、文档等。显然，可以在编码之前不进行功能测试等等。
由于每个人都必须做某事，因此在任何给定时间，至少有与团队成员（或对）一样多的开放任务。考虑到有时任务会因各种原因（任务间依赖性、需要外部各方提供的信息等）而被搁置，通常甚至更多。
在一个由 4 名开发人员组成的团队的 Scrum 项目中，我们遇到了非常相似的情况。我们确实努力尽可能按优先顺序处理故事，通常我们随时都会有多个故事和多个任务。一开始，我们经常在冲刺结束时遇到几个半成品故事的问题。因此，我们意识到将未完成的任务/故事的数量保持在最低限度非常重要，即在开始新任务/故事之前始终尝试先完成未完成的任务/故事。但实际上，这个最小值并不意味着是 1。
至于每个冲刺的故事数量，我们只是根据我们（故事，然后是任务级别）的估计放入尽可能多的故事。这当然很大程度上受到我们的速度的影响，一开始我们对速度的估计太高了。几个月后，我们将其降低到 60%，这个值似乎对我们有用。
I don't know who says this, I at least don't remember having heard or read anything like the emphasized text so far. Of course, it depends also on whether an item for you is a story or a single task.
If it's a story (usually consisting of several tasks), there might be a chance of achieving this. However, as you say, sometimes the story just doesn't include enough tasks to keep everyone busy. Also often the tasks related to a story strongly depend on each other, e.g. there might be a design session (involving part or whole of team), then one or more coding tasks, then code review, functional testing, documentation etc. Obviously one can't do functional testing before the coding, and so on.
Since everyone has to do something, there will be at least as many tasks open at any given time as there are team members (or pairs). Taking into account that sometimes tasks are on hold for various reasons (inter-task dependencies, information needed from external parties etc.), usually even more.
In one Scrum project with a team of 4 developers, we had a very similar situation. We did strive to take stories in priority order as much as possible, and usually we had multiple stories and several tasks open at any time. In the beginning we often had problems with several half-finished stories at the end of the sprint. So we realized it is important to keep the number of open tasks / stories to a minimum, i.e. always attempt to finish open tasks /stories first before starting a new one. But practically, that minimum was never meant to be 1.
As for the number of stories per sprint, we just put in as many as we could comfortably fit in based on our (story, then task level) estimations. That was of course greatly influenced by our velocity, which in the beginning was estimated too high. After a couple of months we chipped it down to 60%, and that value seemed to work for us.
整个团队处理每个项目的建议是避免在冲刺中创建小型瀑布，即项目从一个专门小组传递到另一个专门小组。这会导致测试人员在冲刺的第一天无事可做，然后在最后几天加班，而编码员则在摆弄拇指。团队应该从整体上解决问题，让每个人都参与进来，即使是在他们各自的“专业”之外。是的，编码员可以测试，测试员可以编码，两者都可以设计架构等 - 并且在这个过程中学习新的东西（令人惊奇）。这并不是说每个人都应该擅长所有事情 - 只是说“我不测试，我是一名程序员”或“我不会写这个脚本，我是一名测试人员”这样的态度应该在 Scrum 团队中没有地位。
还建议在冲刺期间逐一处理项目，以确保最终确实交付某些内容。限制在制品 (WIP) 可防止出现以下情况：每个人都对每个项目完成了一些任务，但到冲刺结束时尚未完成任何项目。
然而，这不应被视为建议，而不是非常严格的规则。例如，当您有两个小故事和一个 10 人团队时，让所有团队都集中在一个故事上可能没有意义。
底线是：没有人应该告诉团队如何在他们之间分配工作，但应该期望交付他们在 Sprint Planning 中承诺的内容。
The advice to approach each item by the whole team is there to avoid creating mini-waterfalls within sprints, where items are passed from one specialized group to another. That leads to stuff like testers having nothing to do in first days of the sprint, then working overtime for the last couple of days when coders fiddle their thumbs. Teams should approach the problem as a whole with everyone chipping in, even outside of their respective "specialization". Yes, coders can test, testers can code and both can design architectures etc. - and in the process learn something new (amazing). That is not to say everyone should be very good at everything - it is just to say attitude like "I don't test, I'm a coder" or "I won't write this script, I'm a tester" should have no place in a Scrum team.
It is also advised to tackle items one by one inside of sprint to make sure something is actually delivered at the end. Limiting work in progress (WIP) prevents situation, where everyone did some tasks on each item, but no item has been completed by sprint's end.
However, this shouldn't be viewed as advice, not a very strict rule. For example when you have two small stories and a team of 10 it probably doesn't make sense to have all of the team swarm on just one story.
Bottom line is: no one should tell the team how to divide work among themselves, but delivering what they committed to at Sprint Planning should be expected.
我认为这取决于你的团队的构成。如果您有一个团队，任何人都可以承担用户故事中的任何给定任务，那么这很有效。如果你不这样做，那么某些人可能会有空闲时间。
根据优先级处理用户故事的要点很简单......您首先完成优先级最高的用户故事。从实际设置优先级的客户的角度来看，这增加了最大的价值。
至于在冲刺期间要提交多少个用户故事，这取决于几个因素：
团队可用性、团队速度和冲刺持续时间。因此，我不确定通过了解其他人在冲刺期间处理了多少故事，您能获得多少价值。
I think it depends on the makeup of your team. If you have a team where anyone can take on any given task within a user story, then this works well. If you do not, then there will likely be idle time for some individuals.
The point in working the user stories based on priority is simple... you get the highest priority user story completed first. This adds the most value from the perspective of the customer who actually set the priority.
As for how many user stories to commit to during a sprint, that depends on a few factors:
Team Availability, Team Velocity, and Sprint Duration. So, I'm not sure how much value you will get out of knowing how many stories other people tackle during a sprint.
Noel，您的团队接受过在 Scrum 团队中工作的培训吗？我的意思是，在项目开始之前，您是否将他们送去参加 Scrum 课程？
我见过很多团队在 Scrum 方面失败，只是因为他们误解了博客上一本书中所写的内容。
另外，拥有一位经验丰富的 Scrum Practitioner 或 Scrum Coach 也会对你有很大帮助。
要具体回答您的问题，请查看这本与其他书籍不同的免费电子书：
http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf
Noel, is your team trained to work in a Scrum team ? I mean did you send them to Scrum Course prior beginning the project ?
I've seen so many team failing with Scrum just because they misunderstood what was written in a book on a blog.
Also having an experienced Scrum Practitioner or Scrum Coach will help you a lot.
To answer your question specifically, check this nice free ebook that is different than others:
http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf