Option 1 of course. Your velocity for the next iteration is going to be less, as it is based on yesterdays weather, so the next iteration you have a better chance of being complete.
In scrum you are time-boxing. And you only deliver features that work.
In the sprint planning you have made an estimate of what you could deliver. The customer has to accept a certain level of uncertainty in the estimate, or be prepared to have too many resources on the team.
If you miss the next iteration again, switch to a shorter iteration length, and make sure the size of individual features is smaller.
You would normally do option 1 - finish the sprint. Use the completed work, let the unfinished work get reflected in the project velocity - so future planning takes account of the difficulties you experienced.
Yes, option 1 means we didn't finish what we committed to - but if that's what's happened then it's better to admit it and learn to cope better next time than to hide it. Bad stuff happens to everybody - the critical thing is how we improve from where we are.
You could do option 2 - continue finishing the outstanding work by extending the sprint. Only do this if the work is super-high priority to the customer and they explicitly choose to do it. Extending the length of sprints makes them harder to compare with each other - because they're different lengths.
Absolutely NEVER never let one sprint merge into the next - either you're extending the old sprint, or you're starting a completely new one. If you let two sprints merge into each other then you're not really doing sprints anymore and planning breaks down...
Can I answer with "It depends"? Plus, I'd like to throw in a "Define complete".
We've had this situation a couple of times and dealt with it differently depending on the circumstances.
As far as I remember in two cases we let the sprint fail. It was actually more of a demo-rejected kind of fail. The features themselves were considered complete by the team, but there were too many open questions, loose ends and little details that popped up during the demo. It would have taken a couple of days to wrap everything up, so we let the sprint fail and took all the open items into the next sprint. We still had a retrospective and sprint planning for new user stories, but there was no integration of code lines and the sprint was officially marked as failed.
In another case we only had a couple of bugs that turned up last minute, plus a couple of things from the user story. We estimated the total work to three days tops and just extended the sprint. That was enough for us to fix the bug, make a couple of changes and do a second sprint demo about three days later.
So, it was either option 4 or option 2 for us when it was called for.
There are a few things to consider here. First of all, (and I'm talking Scrum terminology here, because I'm used to it, so feel free to substitute it with whatever fits best) get the ScrumMaster, Product Owner and the team together and discuss the options openly. I don't think there's one way to go. You can stick to pure methodology, but in real life that's not always the best way to go. Sometimes bending the rules a bit helps a lot and makes life easier for everyone.
If you're working well together you should find an option that works for everyone involved. (If you can't you may have underlying problems anyway.) Don't just drop something on the team without at least discussing it or at least explaining the reasons why.
Option 3 sounds like the most messy to me, so I'd rule that out.
A lot of people here have argued that option 2 goes against basic agile (or Scrum) rules, but I'd disagree. Scrum explicitly says that you can extend the sprint if called for, the same as you can reduce stories or add resources. You shouldn't do it until absolutely necessary, but as far as I know it's not strictly against the book. In the base when we did it, it was the best solution for everyone, because we still got the sprint done, only three days later and everyone was very happy with the results. If we were talking a week or more option 2 wouldn't have been appropriate.
I don't really like option 1. Taking half-done stuff out a working implementation can be really messy. You lose touch with the code that has been done and integration, frankly, can be a pain. It might be different depending on the way you work, but from my experience, taking code out of a codeline is not something you want to do.
As for option 4, it is pretty harsh, but then again, when communicated correctly it should be okay. The team usually knows when it messed up and won't be able to deliver, so it's not like you're breaking any news to them.
So, there are a few things to consider.
How much time will it need to get it done done? If it's only one or two days, extending your sprint might be the best option.
How much effort will it be to remove the code that's already there? If it's messy and takes up time, resolve to option 2 or 4. If it's easy, maybe option 1 is the way to go.
What does the team think? What does the product owner think? What do others think? Failing a spring might have an impact on team morale, but it might not.
For an agile project it is important to have a 'Definition of done'. This is a small check list of things that need to be done in order to class something as complete. It is not unusual to have different levels of done:
User Story - This could include things such as all tasks associated with the US must be complete, All code is checked in and building successfully with passing unit tests, Acceptance testing has been completed.
Sprint - This could include things such as all stories for the sprint are 'done' (see above, a retrospective has be held, the product owner has seen a demonstration of the functionality etc. etc.
Release sprint - the development of the previous series of sprints has been successfully integrated and regression tested, the functionality has been released into the live environment.
In terms of the 4 options it is less clear cut. A lot is said and has been written about what should and should not be done around failing the sprint, extending the sprint and excluding some feature or other. I find the that with agile projects a lot of pragmatism is required, especially in the first few sprints.
The important thing is not to get hung up it. Just learn from it, adapt and move on.
I'd take a variation on option 1. If feature B can be broken down into what is completed and what isn't completed, this should lead to a revised set of tasks to complete it for the next sprint. What is finished is delivered, and while the delivery isn't perfect, the idea should be to try one's best and then work on what is next according to priority.
Extending the sprint is a recipe for disaster to my mind. Does completing the feature mean resolving all bugs on it, too? Ever seen software that had zero bugs?
Failing the sprint introduces too much perfectionism into things. Is something that is 99% done worthless? I wouldn't think so, but there are some people that have really high standards and can be pretty demanding.
EDIT: Sometimes a feature initially is given with vague requirements that get clarified over the course of the sprint. For example, a feature request of, "As a user, I'd like to place an order," can either be broken down further as part of planning the sprint or during the sprint. In either case, if some stories involving a feature are done, those can and should be presented at the demo if one is done. The point is to be able to say, "This is where we are. How much of a priority is there on finishing this?" as what might have been urgent before may not be so at the end of the sprint.
如果这是真的，那么 B 比 A、D 和 F 更重要，并且您没有首先处理最重要的项目，这是错误的，它不应该发生或者... A、D 和 F 实际上非常有价值，在这种情况下你的假设实际上不正确，因此推迟 B 并不是一个大问题。所以，一旦你意识到它无法完成，就立即去做，看看是否可以用较小的物品替换它。
First, the rule: iterations are fixed-length time-boxes and they are complete at the end of the time-box. So this eliminates Option 2 and Option 3. Regarding Option 4, iteration abnormal termination may occur under very particular circumstances (certainty that the goal cannot be achieved, external event invalidates the goal, ...) but this must remain an exceptional event. And before to abort, there are in general other options: 1. Do something else / innovate 2. Get help / outsource 3. Reduce the scope. And this leaves you with Option 1, the obvious choice.
The problem I see with option 1 is that the team isn't delivering what it committed to. In some cases, you may not be able to exclude feature B without making the entire release useless (or at least substantially less valuable). It may make it difficult to guide the direction of the next sprint without feature B.
If this is true, then either B was more important than A, D and F and you didn't work on the most important items first which is wrong, it shouldn't happen or... A, D and F are actually very valuable in which case your assumption is actually not true and postponing B is thus not a big problem. So, just do it as soon as you realize it won't be done and see if you can replace it with a smaller item.
发布评论
评论（6）
当然是选项1。您下一次迭代的速度将会降低，因为它基于昨天的天气，因此您完成下一次迭代的机会更大。
在 Scrum 中，你要进行时间限制。而且您只提供有效的功能。
在冲刺计划中，您已经对可以交付的内容进行了估计。客户必须接受估计中一定程度的不确定性，或者准备好在团队中拥有太多资源。
如果再次错过下一次迭代，请切换到较短的迭代长度，并确保单个特征的大小更小。
Option 1 of course. Your velocity for the next iteration is going to be less, as it is based on yesterdays weather, so the next iteration you have a better chance of being complete.
In scrum you are time-boxing. And you only deliver features that work.
In the sprint planning you have made an estimate of what you could deliver. The customer has to accept a certain level of uncertainty in the estimate, or be prepared to have too many resources on the team.
If you miss the next iteration again, switch to a shorter iteration length, and make sure the size of individual features is smaller.
您通常会执行选项 1 - 完成冲刺。使用已完成的工作，让未完成的工作反映在项目速度中 - 这样未来的规划就会考虑到您所经历的困难。
是的，选项 1 意味着我们没有完成我们承诺的事情 - 但如果这就是发生的事情，那么最好承认它并学会下次更好地应对，而不是隐藏它。每个人都会遇到不好的事情- 关键是我们如何在现有基础上进行改进。
您可以执行选项 2 - 通过延长冲刺来继续完成未完成的工作。只有当工作对客户来说具有超高优先级并且他们明确选择这样做时才这样做。延长冲刺的长度会使它们更难以相互比较 - 因为它们的长度不同。
绝对永远不要让一个冲刺合并到下一个冲刺中 - 要么延长旧的冲刺，要么开始一个全新的冲刺。如果你让两个冲刺相互合并，那么你就不再真正进行冲刺，并且计划就会崩溃......
You would normally do option 1 - finish the sprint. Use the completed work, let the unfinished work get reflected in the project velocity - so future planning takes account of the difficulties you experienced.
Yes, option 1 means we didn't finish what we committed to - but if that's what's happened then it's better to admit it and learn to cope better next time than to hide it. Bad stuff happens to everybody - the critical thing is how we improve from where we are.
You could do option 2 - continue finishing the outstanding work by extending the sprint. Only do this if the work is super-high priority to the customer and they explicitly choose to do it. Extending the length of sprints makes them harder to compare with each other - because they're different lengths.
Absolutely NEVER never let one sprint merge into the next - either you're extending the old sprint, or you're starting a completely new one. If you let two sprints merge into each other then you're not really doing sprints anymore and planning breaks down...
我可以回答“视情况而定”吗？另外，我想添加一个“定义完成”。
这种情况我们已经遇到过好几次了，根据具体情况采取了不同的处理方式。
据我记得，有两个案例让冲刺失败了。这实际上更像是一次演示被拒绝的失败。团队认为这些功能本身是完整的，但在演示过程中出现了太多悬而未决的问题、未解决的问题和一些小细节。完成所有事情可能需要几天的时间，因此我们让冲刺失败，并将所有未完成的项目带入下一个冲刺。我们仍然对新的用户故事进行回顾和冲刺计划，但没有集成代码行，并且冲刺被正式标记为失败。
在另一种情况下，我们只在最后一刻出现了一些错误，再加上用户故事中的一些内容。我们估计总工作量最多为三天，只是延长了冲刺时间。这足以让我们修复错误、进行一些更改并在大约三天后进行第二次冲刺演示。
因此，当需要时，我们要么选择选项 4，要么选择选项 2。
这里有一些事情需要考虑。首先，（我在这里谈论的是 Scrum 术语，因为我已经习惯了，所以可以随意用最合适的术语来代替它）让 ScrumMaster、产品负责人和团队聚集在一起，公开讨论这些选项。我不认为只有一种方法可以走。您可以坚持纯粹的方法论，但在现实生活中，这并不总是最好的方法。有时稍微改变一下规则会有很大帮助，让每个人的生活变得更轻松。
如果你们合作得很好，你应该找到一个适合所有参与者的选择。 （如果你做不到，那么你可能会遇到潜在的问题。）不要在没有讨论或至少解释原因的情况下就将某些东西扔给团队。
选项 3 对我来说听起来是最混乱的，所以我会排除它。
这里很多人认为选项 2 违反了基本的敏捷（或 Scrum）规则，但我不同意。 Scrum 明确表示，如果需要，您可以延长冲刺，就像减少故事或添加资源一样。除非绝对必要，否则你不应该这样做，但据我所知，这并不严格违反这本书。当我们在基地做的时候，这对每个人来说都是最好的解决方案，因为我们仍然完成了冲刺，仅仅三天后，每个人都对结果非常满意。如果我们谈论一周或更长时间，选项 2 就不合适。
我不太喜欢选项 1。将半成品从工作实现中取出可能会非常混乱。您与已完成的代码失去了联系，坦率地说，集成可能会很痛苦。根据您的工作方式，这可能会有所不同，但根据我的经验，从代码行中取出代码并不是您想要做的事情。
至于选项 4，它相当苛刻，但话又说回来，如果沟通正确，应该没问题。团队通常知道什么时候会出现问题并且无法交付，所以你不会向他们透露任何消息。
因此，有一些事情需要考虑。
Can I answer with "It depends"? Plus, I'd like to throw in a "Define complete".
We've had this situation a couple of times and dealt with it differently depending on the circumstances.
As far as I remember in two cases we let the sprint fail. It was actually more of a demo-rejected kind of fail. The features themselves were considered complete by the team, but there were too many open questions, loose ends and little details that popped up during the demo. It would have taken a couple of days to wrap everything up, so we let the sprint fail and took all the open items into the next sprint. We still had a retrospective and sprint planning for new user stories, but there was no integration of code lines and the sprint was officially marked as failed.
In another case we only had a couple of bugs that turned up last minute, plus a couple of things from the user story. We estimated the total work to three days tops and just extended the sprint. That was enough for us to fix the bug, make a couple of changes and do a second sprint demo about three days later.
So, it was either option 4 or option 2 for us when it was called for.
There are a few things to consider here. First of all, (and I'm talking Scrum terminology here, because I'm used to it, so feel free to substitute it with whatever fits best) get the ScrumMaster, Product Owner and the team together and discuss the options openly. I don't think there's one way to go. You can stick to pure methodology, but in real life that's not always the best way to go. Sometimes bending the rules a bit helps a lot and makes life easier for everyone.
If you're working well together you should find an option that works for everyone involved. (If you can't you may have underlying problems anyway.) Don't just drop something on the team without at least discussing it or at least explaining the reasons why.
Option 3 sounds like the most messy to me, so I'd rule that out.
A lot of people here have argued that option 2 goes against basic agile (or Scrum) rules, but I'd disagree. Scrum explicitly says that you can extend the sprint if called for, the same as you can reduce stories or add resources. You shouldn't do it until absolutely necessary, but as far as I know it's not strictly against the book. In the base when we did it, it was the best solution for everyone, because we still got the sprint done, only three days later and everyone was very happy with the results. If we were talking a week or more option 2 wouldn't have been appropriate.
I don't really like option 1. Taking half-done stuff out a working implementation can be really messy. You lose touch with the code that has been done and integration, frankly, can be a pain. It might be different depending on the way you work, but from my experience, taking code out of a codeline is not something you want to do.
As for option 4, it is pretty harsh, but then again, when communicated correctly it should be okay. The team usually knows when it messed up and won't be able to deliver, so it's not like you're breaking any news to them.
So, there are a few things to consider.
对于敏捷项目来说，“完成的定义”非常重要。这是一个小的检查清单，列出了需要完成的事项，以便将某些内容归类为完整。完成不同级别的工作并不罕见：
用户故事 - 这可能包括诸如必须完成与美国相关的所有任务、所有代码均已签入并通过单元测试成功构建、验收测试已完成等事项。已完成。
冲刺 - 这可能包括诸如冲刺的所有故事都已“完成”之类的事情（参见上文，已举行回顾，产品负责人已经看到了功能演示等。
发布冲刺 - 上一个冲刺的开发系列冲刺已成功集成和回归测试，功能已发布到实际环境中。
就这 4 个选项而言，关于冲刺失败、延长冲刺以及排除某些功能等问题，人们已经说了很多，也写了很多 敏捷项目需要大量的实用主义，特别是在最初的几个冲刺中。
重要的是不要挂断它。只需从中学习、适应并继续前进。
For an agile project it is important to have a 'Definition of done'. This is a small check list of things that need to be done in order to class something as complete. It is not unusual to have different levels of done:
User Story - This could include things such as all tasks associated with the US must be complete, All code is checked in and building successfully with passing unit tests, Acceptance testing has been completed.
Sprint - This could include things such as all stories for the sprint are 'done' (see above, a retrospective has be held, the product owner has seen a demonstration of the functionality etc. etc.
Release sprint - the development of the previous series of sprints has been successfully integrated and regression tested, the functionality has been released into the live environment.
In terms of the 4 options it is less clear cut. A lot is said and has been written about what should and should not be done around failing the sprint, extending the sprint and excluding some feature or other. I find the that with agile projects a lot of pragmatism is required, especially in the first few sprints.
The important thing is not to get hung up it. Just learn from it, adapt and move on.
我会对选项 1 采取变体。如果功能 B 可以分解为已完成的内容和未完成的内容，那么这应该会导致修改一组任务以在下一个冲刺中完成它。完成的事情就交付了，虽然交付并不完美，但我们的想法应该是尽力而为，然后根据优先级处理下一步的工作。
在我看来，延长冲刺时间会带来灾难。完成该功能是否也意味着解决其中的所有错误？你见过零错误的软件吗？
冲刺失败会给事情带来太多的完美主义。 99%完成的事情就毫无价值了吗？我不这么认为，但有些人的标准非常高，要求也很高。
编辑：有时，某个功能最初会给出模糊的要求，但在冲刺过程中会得到澄清。例如，“作为用户，我想下订单”的功能请求可以作为冲刺计划的一部分或冲刺期间进一步细分。在任何一种情况下，如果涉及某个功能的一些故事已经完成，那么这些故事可以而且应该在演示中呈现（如果完成了）。关键是要能够说：“这就是我们现在的处境。完成这件事有多少优先级？”因为之前可能紧急的事情在冲刺结束时可能并不那么紧急。
I'd take a variation on option 1. If feature B can be broken down into what is completed and what isn't completed, this should lead to a revised set of tasks to complete it for the next sprint. What is finished is delivered, and while the delivery isn't perfect, the idea should be to try one's best and then work on what is next according to priority.
Extending the sprint is a recipe for disaster to my mind. Does completing the feature mean resolving all bugs on it, too? Ever seen software that had zero bugs?
Failing the sprint introduces too much perfectionism into things. Is something that is 99% done worthless? I wouldn't think so, but there are some people that have really high standards and can be pretty demanding.
EDIT: Sometimes a feature initially is given with vague requirements that get clarified over the course of the sprint. For example, a feature request of, "As a user, I'd like to place an order," can either be broken down further as part of planning the sprint or during the sprint. In either case, if some stories involving a feature are done, those can and should be presented at the demo if one is done. The point is to be able to say, "This is where we are. How much of a priority is there on finishing this?" as what might have been urgent before may not be so at the end of the sprint.
首先，规则：迭代是固定长度的时间盒，并且它们在时间盒结束时完成。因此，这消除了选项 2 和选项 3。对于选项 4，迭代异常终止可能在非常特殊的情况下发生（确定目标无法实现、外部事件使目标无效……），但这必须仍然是异常事件。在中止之前，通常还有其他选择： 1. 做其他事情/创新 2. 获得帮助/外包 3. 缩小范围。这给你留下了选项 1，这是显而易见的选择。
如果这是真的，那么 B 比 A、D 和 F 更重要，并且您没有首先处理最重要的项目，这是错误的，它不应该发生或者... A、D 和 F 实际上非常有价值，在这种情况下你的假设实际上不正确，因此推迟 B 并不是一个大问题。所以，一旦你意识到它无法完成，就立即去做，看看是否可以用较小的物品替换它。
First, the rule: iterations are fixed-length time-boxes and they are complete at the end of the time-box. So this eliminates Option 2 and Option 3. Regarding Option 4, iteration abnormal termination may occur under very particular circumstances (certainty that the goal cannot be achieved, external event invalidates the goal, ...) but this must remain an exceptional event. And before to abort, there are in general other options: 1. Do something else / innovate 2. Get help / outsource 3. Reduce the scope. And this leaves you with Option 1, the obvious choice.
If this is true, then either B was more important than A, D and F and you didn't work on the most important items first which is wrong, it shouldn't happen or... A, D and F are actually very valuable in which case your assumption is actually not true and postponing B is thus not a big problem. So, just do it as soon as you realize it won't be done and see if you can replace it with a smaller item.