My teams have always picked items up from the backlog, starting with the highest-priority items that can fit in the remaining time.
If nothing quite fits that criteria (as when there's only half a day left and/or no small stories to pick up), consider paying down some technical debt.
Do anything that the team thinks should be done but doesn't belong on a card because there's no visible business value. Some people have called these tasks "technical stories". They tend to be things you should have done before Sprint 0, but didn't. Examples include adding of these that you don't already have to the build:
One thing I recommend is looking up future tasks and doing some detailed planning for estimates. This is non trivial and will take some time. Another is to scope of a new large scale project that can be broken into tasks and entered in product backlog.
(...) what do you do to keep everyone working as the sprint moves into its final stages?
Nothing, I expect a self-organized team to find out this by themselves. And there are many options (by order of importance):
Help other members of the team to finish their stories (achieving the goal of the sprint is the most important, the whole team succeed or fail at this, not individuals).
Prepare a kick-ass demo.
Pick up a story from the backlog that can be done-done before the end of the sprint (i.e. not always the next highest priority items but something that fit in terms of size).
Repay technical debt if you have some.
Document things if this make sense.
Explore new things (tools, frameworks, testing techniques, etc) that may be useful for the team.
此外，正如 Mike Cohn 在他的书中所建议的，通过敏捷取得成功团队可能希望预留大约 10% 的时间用于一些前瞻性计划。这可能涉及与产品负责人召开会议，讨论未来冲刺的一些即将到来的故事，将较大的故事分解为较小的故事，或者对于设计师来说，可能会为即将到来的故事做一些线框或模型。
一旦达到这种状态，您才应该考虑继续处理产品待办事项列表。
While it may seem obvious for team members to move on to the next highest items in the product backlog, I would advise against starting with this.
First and foremost, the teams' obligation is to achieving the sprint goal, so anything they can do to work towards that must come first (e.g. helping out testing, chipping in where possible, etc.).
Next, the team should look at expanding their definition of "done". Perhaps it currently doesn't include testing, or doesn't include some form of code review. Most teams starting with Scrum do not start with a definition of done that truly has a product increment that is ready to ship, so now would be the team to move towards that.
As others have mentioned, what tools do you need setup in order to get closer to a shippable state? Continuous integration? Automated acceptance tests? Now is the time to add these things.
Likely, you also have areas of the code that existed before you moved to Scrum and thus don't have very good test coverage or have accumulated technical debt. Now's the time to pay that off.
Also, as Mike Cohn suggests in his book Succeeding with Agile teams may want to reserve roughly 10% of their time for some look ahead planning. This may involve having a meeting with the Product Owner to discuss some up and coming stories for future sprints, breaking down larger stories into smaller ones, or for designers, perhaps doing some wire frames or mock-ups for upcoming stories.
Once you've gotten to this state, only then should you consider continuing on with the product backlog.
When there are team members that have completed there task early and find themselfs unoccupied there are a few things that can be done.
Make sure that estimation can be improved so hence planning can be improved. In doing this, bare in mind this estimation is very subjective. (However in my view underestimation is a situation we do not want to be in).
The scrum master has to bring in an ethos to the team of "Forwarding thinking"; improvements in oneself, in team productivity and the product or business the team is working on.
2.1. Try help out other team members task where possible to get stories Done (DOD) in the the sprint.
This could be pair work (pair programming)
As a programmer fixing other peoples bugs
etc etc
2.2. Try to help the scrum-master with other stories in he backlog. Check if any small story can be completed within the capacity of sprint making sure of it Impact to the sprint.
2.3. Work on research where there is a story in the backlog which is unclear. Do research on this story. Here a new story can be created with the emphasis on delivering research results. This story should be 0 points. programming prototyping etc can be done on the developers local PC without it being checked in.
2.4. Develop ones own skill either in there functional area (programming, testing etc) or the domain area.
The idea is a team that is performing. Each team member is dedicated to the goals of the team. So if you find yourself free...forward think how can i help the goals of the team.
发布评论
评论（8）
我的团队总是从积压的项目中挑选项目，从可以在剩余时间内完成的最高优先级的项目开始。
如果没有什么完全符合该标准（例如只剩下半天时间和/或没有小故事可供选择），请考虑支付一些技术债务。
My teams have always picked items up from the backlog, starting with the highest-priority items that can fit in the remaining time.
If nothing quite fits that criteria (as when there's only half a day left and/or no small stories to pick up), consider paying down some technical debt.
Scrum 是由团队完成的。
如果有些人完成了，他们可以帮助其团队的其他成员。。
他们还可以帮助他们的团队在下一个冲刺中取得领先。
他们还可以对新技术进行一些探索，如果这对团队有帮助的话。
或者他们可以提高自己的技能，如果这对团队有帮助的话。
他们可以创建培训材料来帮助团队的其他成员提高技能。
这是团队的决定。
Scrum is done by teams.
If some people are done, they can help other members of their team.
They can also help their team by getting a head start on the next sprint.
They can also do some exploration of new technology, if that would help the team.
Or they could brush up their own skills, if that would help the team.
They could create training materials to help other members of the team improve their skills.
That's a team decision.
我建议的一件事是查找未来的任务并为估算做一些详细的计划。这并非易事，需要一些时间。另一个是确定新的大型项目的范围，该项目可以分解为任务并输入产品待办事项列表中。
One thing I recommend is looking up future tasks and doing some detailed planning for estimates. This is non trivial and will take some time. Another is to scope of a new large scale project that can be broken into tasks and entered in product backlog.
重构、编写单元测试、改进技能。
Refactoring, writing unit-tests, improvement skills.
没什么，我期望一个自组织团队自己找出这个问题。并且有很多选择（按重要性排序）：
Nothing, I expect a self-organized team to find out this by themselves. And there are many options (by order of importance):
虽然对于团队成员来说，继续处理产品积压中下一个最高的项目似乎是显而易见的，但我建议不要从这个开始。
首先也是最重要的，团队的义务是实现冲刺目标，因此他们可以做的任何事情都必须放在第一位（例如帮助测试、尽可能地参与等）。
接下来，团队应该考虑扩展他们对“完成”的定义。也许它目前不包括测试，或者不包括某种形式的代码审查。大多数从 Scrum 开始的团队并不是从真正具有准备交付的产品增量的“完成”定义开始，因此现在是团队朝着这个目标迈进的时候。
正如其他人提到的，您需要设置哪些工具才能接近可交付状态？持续集成？自动验收测试？现在是添加这些内容的时候了。
很可能，您的代码区域在迁移到 Scrum 之前就已存在，因此没有很好的测试覆盖率或积累了技术债务。现在是还债的时候了。
此外，正如 Mike Cohn 在他的书中所建议的，通过敏捷取得成功团队可能希望预留大约 10% 的时间用于一些前瞻性计划。这可能涉及与产品负责人召开会议，讨论未来冲刺的一些即将到来的故事，将较大的故事分解为较小的故事，或者对于设计师来说，可能会为即将到来的故事做一些线框或模型。
一旦达到这种状态，您才应该考虑继续处理产品待办事项列表。
While it may seem obvious for team members to move on to the next highest items in the product backlog, I would advise against starting with this.
First and foremost, the teams' obligation is to achieving the sprint goal, so anything they can do to work towards that must come first (e.g. helping out testing, chipping in where possible, etc.).
Next, the team should look at expanding their definition of "done". Perhaps it currently doesn't include testing, or doesn't include some form of code review. Most teams starting with Scrum do not start with a definition of done that truly has a product increment that is ready to ship, so now would be the team to move towards that.
As others have mentioned, what tools do you need setup in order to get closer to a shippable state? Continuous integration? Automated acceptance tests? Now is the time to add these things.
Likely, you also have areas of the code that existed before you moved to Scrum and thus don't have very good test coverage or have accumulated technical debt. Now's the time to pay that off.
Also, as Mike Cohn suggests in his book Succeeding with Agile teams may want to reserve roughly 10% of their time for some look ahead planning. This may involve having a meeting with the Product Owner to discuss some up and coming stories for future sprints, breaking down larger stories into smaller ones, or for designers, perhaps doing some wire frames or mock-ups for upcoming stories.
Once you've gotten to this state, only then should you consider continuing on with the product backlog.
当团队成员提前完成任务并发现自己闲置时，可以做一些事情。
确保可以改进估算，从而改进规划。在这样做时，请记住，这种估计是非常主观的。 （但是，在我看来，低估是我们不希望出现的情况）。
Scrum Master 必须给团队带来一种“转发思维”的精神；自我改进、团队生产力以及团队正在开发的产品或业务的改进。
2.1.尽可能帮助其他团队成员完成任务，以在冲刺中完成故事 (DOD)。
这可以是结对工作（结对编程）
作为一名修复其他人的错误的程序员
等等
2.2。尝试帮助 scrum-master 处理待办事项中的其他故事。检查是否有任何小故事可以在冲刺的能力范围内完成，确保它对冲刺的影响。
2.3.进行研究，积压的工作中存在不清楚的故事。对这个故事进行研究。在这里可以创造一个新的故事，重点是提供研究成果。这个故事应该是0分。编程原型等可以在开发人员本地 PC 上完成，无需签入。2.4
。发展自己在职能领域（编程、测试等）或领域的技能。
这个想法是一个正在执行的团队。每个团队成员都致力于团队的目标。所以，如果你发现自己有空……向前思考我怎样才能帮助团队实现目标。
When there are team members that have completed there task early and find themselfs unoccupied there are a few things that can be done.
Make sure that estimation can be improved so hence planning can be improved. In doing this, bare in mind this estimation is very subjective. (However in my view underestimation is a situation we do not want to be in).
The scrum master has to bring in an ethos to the team of "Forwarding thinking"; improvements in oneself, in team productivity and the product or business the team is working on.
2.1. Try help out other team members task where possible to get stories Done (DOD) in the the sprint.
This could be pair work (pair programming)
As a programmer fixing other peoples bugs
etc etc
2.2. Try to help the scrum-master with other stories in he backlog. Check if any small story can be completed within the capacity of sprint making sure of it Impact to the sprint.
2.3. Work on research where there is a story in the backlog which is unclear. Do research on this story. Here a new story can be created with the emphasis on delivering research results. This story should be 0 points. programming prototyping etc can be done on the developers local PC without it being checked in.
2.4. Develop ones own skill either in there functional area (programming, testing etc) or the domain area.
The idea is a team that is performing. Each team member is dedicated to the goals of the team. So if you find yourself free...forward think how can i help the goals of the team.