Yes. And this is important: Don't accept changes to stories after a sprint starts.
This will take much effort on behalf of scrum masters to tell the product owners that this is not permitted. The important thing to emphasise to them is that as developers you undertake to estimate and deliver the stories as specified, and any changes negates that effort.
In some cases the requirements legitimately change after a sprint starts. Here, consider aborting the sprint altogether. (That should get their attention.)
If your product owner finds that this is too inflexible, consider reducing the spring length. I've worked in a shop that used a sprint of one week, which I reckon to be the minimum, as the stories ended up being very small.
Bring your stakeholders to the scrums; invovling them will elimate any "chinese whispers" through the product managers. Also it is they that need to prioritise the back log not the developers. When the stakeholders are at the scrums they also see the ramifications of change better and whilst they won't stop making changes, they will have a better concept of how their changes effect the iteration.
On changing requirements; see the Agile Manifesto ... "Embrace change!"
"Meanwhile, the sprint start date is upon us and we start grabbing at the requirements we are pretty sure are stable. Once those are done we are left with endless days of tweaking the code as the requirements shift around slightly."
Please do not call that an Agile method or scrum.
That's just craziness.
If you're tweaking things after the sprint starts, you're not doing it right.
You're enabling (indeed, your encouraging) bad behavior. If they can't get the requirements before the sprint starts, you have two choices.
Wait. Nothing wrong with this. It's cheaper in the long run.
Start. However. Since the requirements are fixed for the duration of the sprint, you have to finish the sprint with no "tweaking". Changes become part of the backlog.
You can do shorter sprints.
You can simply backlog the tweaks until they get the idea that they're causing their own problems.
Also, a lot of management review is not very Agile. It's not per se wrong. But it indicates a lack of trust. Agile means collaboration and interaction between developers and product owners. It doesn't mean another layer of management review.
We have someone in the team that is in charge of fixing the requirements on behalf of the Product owner. Sometimes we have just-in-time requirements, sometimes, we have some rework to do. QA accepts the requirements are reviewed formally in the latest sprints of the release.
The team should only commit for tasks that are clearly defined by the Product Owner, otherwise they cannot be estimated. Perhaps you could shorten your iteration so that only stable requirements can be planned ?
If your process mandates this review cycle, then perhaps you can restrict your sprintable items to those approved by the product manager/management/stakeholder.
It looks like nobody is really owning the Product Backlog (i.e. you don't have a unique Product Owner) and it looks like the most important Product Backlog Items aren't in a ready state before each iteration. These are obvious major impediments, they need to be solved, your ScrumMaster should work on them.
I agree with the others; your Product Owner is non-existent. You really can't start a sprint until you have enough solid requirements to make a commitment, and your Product Owner agrees with that commitment. Once the commitment is made, neither party can change it within the context of Scrum unless you abandon the sprint and re-plan. Of course, you're not doing this.
I would further state that your Scrum Master is not following his or her responsibilities as Keeper of the Process. Why is he letting you start up a sprint when you don't have a valid product backlog to choose your sprint backlog items from? Do you even have a Scrum Master?
I understand that your team is just trying to get work done, but what is really happening is that you're enabling bad behavior on the part of the product managers, who don't need to have a backlog with well-defined user stories ready before the start of the sprint.
There's a reason that Scrum has a Scrum Master and a Product Owner, and requires agreement between the Product Owner and team on the sprint backlog before the sprint starts. Not having these assigned roles and not following the Scrum process causes things to break. Yes, it's easier to avoid the parts of Scrum that point out bad behavior, but you won't change bad behavior until it is acknowledged. Remember, the definition of insanity is doing the same thing over and over while expecting different results. You're going to have to change what you do if you want to change the results.
发布评论
评论（6）
是的。这很重要：不要在冲刺开始后接受对故事的更改。
这需要 Scrum Master 付出很大的努力来告诉产品负责人这是不允许的。需要向他们强调的重要一点是，作为开发人员，您必须按照指定的方式估计和交付故事，任何更改都会抵消这种努力。
在某些情况下，需求在冲刺开始后会发生合理的变化。在这里，考虑完全中止冲刺。 （这应该引起他们的注意。）
如果您的产品负责人发现这太不灵活，请考虑减少弹簧长度。我曾在一家商店工作过，用了一周的冲刺时间，我认为这是最短的时间，因为故事最终很小。
有关更多详细信息，请参阅 Ken Schwaber 的使用 Scrum 进行敏捷项目管理。
Yes. And this is important: Don't accept changes to stories after a sprint starts.
This will take much effort on behalf of scrum masters to tell the product owners that this is not permitted. The important thing to emphasise to them is that as developers you undertake to estimate and deliver the stories as specified, and any changes negates that effort.
In some cases the requirements legitimately change after a sprint starts. Here, consider aborting the sprint altogether. (That should get their attention.)
If your product owner finds that this is too inflexible, consider reducing the spring length. I've worked in a shop that used a sprint of one week, which I reckon to be the minimum, as the stories ended up being very small.
For more details see Agile Project Management with Scrum by Ken Schwaber.
让您的利益相关者参与 Scrum；让他们参与进来将消除产品经理的任何“中国私语”。此外，需要优先考虑待办事项的是他们，而不是开发人员。当利益相关者参与 Scrum 时，他们也会更好地看到变更的后果，虽然他们不会停止进行变更，但他们会对变更如何影响迭代有更好的概念。
关于不断变化的需求；请参阅敏捷宣言...“拥抱变化！”
善良，
丹
Bring your stakeholders to the scrums; invovling them will elimate any "chinese whispers" through the product managers. Also it is they that need to prioritise the back log not the developers. When the stakeholders are at the scrums they also see the ramifications of change better and whilst they won't stop making changes, they will have a better concept of how their changes effect the iteration.
On changing requirements; see the Agile Manifesto ... "Embrace change!"
Kindness,
Dan
“与此同时，冲刺开始日期即将到来，我们开始抓住我们非常确定稳定的需求。一旦完成这些工作，随着需求略有变化，我们将需要无休止地调整代码。”
请不要称其为敏捷方法或 Scrum。
这太疯狂了。
如果您在冲刺开始后进行调整，那么您就做得不对。
你正在纵容（事实上，你鼓励）不良行为。如果他们在冲刺开始之前无法获得需求，您有两种选择。
等等。这没有什么问题。从长远来看它更便宜。
开始。然而。由于需求在冲刺期间是固定的，因此您必须在没有“调整”的情况下完成冲刺。更改成为待办事项的一部分。
您可以进行更短的冲刺。
您可以简单地积压调整，直到他们意识到自己造成了问题。
而且，很多管理评审都不是很敏捷。这本身并没有错。但这表明缺乏信任。敏捷意味着开发人员和产品负责人之间的协作和互动。这并不意味着另一层管理审查。
"Meanwhile, the sprint start date is upon us and we start grabbing at the requirements we are pretty sure are stable. Once those are done we are left with endless days of tweaking the code as the requirements shift around slightly."
Please do not call that an Agile method or scrum.
That's just craziness.
If you're tweaking things after the sprint starts, you're not doing it right.
You're enabling (indeed, your encouraging) bad behavior. If they can't get the requirements before the sprint starts, you have two choices.
Wait. Nothing wrong with this. It's cheaper in the long run.
Start. However. Since the requirements are fixed for the duration of the sprint, you have to finish the sprint with no "tweaking". Changes become part of the backlog.
You can do shorter sprints.
You can simply backlog the tweaks until they get the idea that they're causing their own problems.
Also, a lot of management review is not very Agile. It's not per se wrong. But it indicates a lack of trust. Agile means collaboration and interaction between developers and product owners. It doesn't mean another layer of management review.
我们团队中有专人负责代表产品所有者确定需求。有时我们有即时要求，有时我们需要返工。 QA 接受在最新版本的冲刺中正式审查的要求。
团队应该只致力于产品负责人明确定义的任务，否则无法估计。也许您可以缩短迭代，以便只规划稳定的需求？
如果您的流程强制执行此审核周期，那么您也许可以将可冲刺项目限制为产品经理/管理层/利益相关者批准的项目。
We have someone in the team that is in charge of fixing the requirements on behalf of the Product owner. Sometimes we have just-in-time requirements, sometimes, we have some rework to do. QA accepts the requirements are reviewed formally in the latest sprints of the release.
The team should only commit for tasks that are clearly defined by the Product Owner, otherwise they cannot be estimated. Perhaps you could shorten your iteration so that only stable requirements can be planned ?
If your process mandates this review cycle, then perhaps you can restrict your sprintable items to those approved by the product manager/management/stakeholder.
看起来没有人真正拥有产品待办事项列表（即您没有唯一的产品负责人），并且看起来最重要的产品待办事项列表项在每次迭代之前都没有处于就绪状态。这些都是明显的主要障碍，需要解决它们，你的 ScrumMaster 应该致力于解决它们。
It looks like nobody is really owning the Product Backlog (i.e. you don't have a unique Product Owner) and it looks like the most important Product Backlog Items aren't in a ready state before each iteration. These are obvious major impediments, they need to be solved, your ScrumMaster should work on them.
我同意其他人的观点；你的产品负责人不存在。除非您有足够可靠的需求来做出承诺，并且您的产品负责人同意该承诺，否则您确实无法开始冲刺。一旦做出承诺，任何一方都不能在 Scrum 的背景下更改它，除非您放弃冲刺并重新计划。当然，你不会这样做。
我想进一步指出，您的 Scrum Master 没有履行其作为流程守护者的职责。当您没有有效的产品待办事项列表可供选择冲刺待办事项列表项时，为什么他让您启动冲刺？你甚至有 Scrum Master 吗？
我知道您的团队只是想完成工作，但真正发生的情况是，您正在助长产品经理的不良行为，他们不需要准备好定义明确的用户故事的积压工作在冲刺开始之前。
Scrum 有一个 Scrum Master 和一个产品负责人，并且需要产品负责人和团队在冲刺开始之前就冲刺待办事项达成一致，这是有原因的。没有分配这些角色并且不遵循 Scrum 流程会导致事情崩溃。是的，避免 Scrum 中指出不良行为的部分更容易，但在不良行为得到承认之前，您不会改变它。请记住，疯狂的定义是一遍又一遍地做同样的事情，却期待不同的结果。如果你想改变结果，你就必须改变你所做的事情。
I agree with the others; your Product Owner is non-existent. You really can't start a sprint until you have enough solid requirements to make a commitment, and your Product Owner agrees with that commitment. Once the commitment is made, neither party can change it within the context of Scrum unless you abandon the sprint and re-plan. Of course, you're not doing this.
I would further state that your Scrum Master is not following his or her responsibilities as Keeper of the Process. Why is he letting you start up a sprint when you don't have a valid product backlog to choose your sprint backlog items from? Do you even have a Scrum Master?
I understand that your team is just trying to get work done, but what is really happening is that you're enabling bad behavior on the part of the product managers, who don't need to have a backlog with well-defined user stories ready before the start of the sprint.
There's a reason that Scrum has a Scrum Master and a Product Owner, and requires agreement between the Product Owner and team on the sprint backlog before the sprint starts. Not having these assigned roles and not following the Scrum process causes things to break. Yes, it's easier to avoid the parts of Scrum that point out bad behavior, but you won't change bad behavior until it is acknowledged. Remember, the definition of insanity is doing the same thing over and over while expecting different results. You're going to have to change what you do if you want to change the results.