现在，SM 在无法顺利工作的情况下究竟应该如何行动很大程度上取决于具体情况。 不过，我宁愿看到他在 PO 和团队之间促进良好的关系和沟通文化，而不是让他保护团队免受 PO 的影响。
The responsibilities are very clearly defined in Scrum - the Product Owner defines backlog items and prioritizes them, the developers commit on how much they can do in a Sprint.
So, a Product Owner simply has no authority at all to set estimates. Of course he can still say that he needs something to a specific point in time - that simply happens. But it's still the developers who will say whether it can be done. And if it can't, they have to work out together on how to change the scope or whatever else can be done to get the needs of the PO fulfilled as best as possible.
Now, how exactly the SM should act in a situation where this doesn't work smoothly depends a lot on the specific situation. I'd rather see him facilitate a good relationship and communication culture between the PO and the team than have him shield the team from the PO, though.
"there has to be guidance as to what amount of time should be spent on data model, etc."
Right. That's what prioritization is all about. You define the work, you prioritize. You work according to the priorities.
What can get out of control?
Redefining the work before anything gets done?
Redefining the priorities before the work gets done?
The solution is the same. Break the work into smaller pieces so something gets done before there's an opportunity to make a change.
If you have short (2-week) sprints, it's not possible to be out of control. If you go for slightly more practical 4-week sprints, then you have a small chance of getting into trouble.
产品是全部，而不仅仅是“功能需求”（借用术语）。坚持认为 PO 不需要试图推迟了解需要完成的幕后工作范围。一旦 PO 开始关注整个范围，那么他们实际上可以成为更广泛的范围的代表。 。
最终，您的 SM 是负责执行流程的人 他们应该这样做。
I don't think it's a question of "out of control".
"I need those screens before the next meeting with the Operating Committee next week, so prioritize those work products first. We'll tackle the database after we talk to Operations."
There is nothing inherently wrong with that statement by itself. If your app is properly abstracted, then your DB is separate anyway. The main problem with UI first is more psychological: The non-devs will assume that most of the work is done if they see screens and go bonkers when things "slow down". However, here's what I think your real problem could be:
The person you have flagged as a Product Owner is not owning the product, and so isn't taking on enough responsibility.
The product is the whole thing, not just the "functional requirements" (to borrow terminology). Your SM needs to have a sit down and be adamant that the PO needs to not try to push off understanding the scope of the behind the scenes work that needs to be accomplished. Once you're PO starts to look at the entire scope, then they can actually be your representative to the broader stakeholder community.
Ultimately, your SM is the one in charge of enforcing process. They should act like it.
I've used Agile at two different shops, both times it works well. I don't see how an out of control anything can ruin the system. Before the sprint, you plan all the tasks you will do and guesstimate how long they will take (always round up). Then you can figure out approximately how much work can be done during your sprint.
Most shops use 4 week sprints, and 6.5hrs of workable time a day. When a sprint has been set, you don't introduce new tasks and only unplanned work that creeps into a sprint is fixing bugs in the features you are adding, of course that is suppose to be included in your guesstimate time.
If you want a more specific answer, you need to define what you mean by an "out of control" product owner.
You probably have some kind of R&D manager (that is not necessarily scrum master) and that is not a product owner).
This guy can and should (I think) "protect" developers. We were in situation when we had such a guy, and it worked pretty well. He helped us with getting non-functional stuff in the backlog for instance.
Now we don't have this guy. Our manager is scrum master. And he does pretty good job protecting us as well. Though...the problem here is that generic scrum master has no official power, so he cannot say "you are not going to press them this much", but he of course can and should talk if he sees that teem needs help.
The team itself and product owner also evolve with time so that they start to care more of each other. Product owner understands when the team just does not commit to more or says "we need some time for non-functional stuff now".
But then - again - it's nice of course if there's a separate R&D manager whose main responsibility is taking care of developers...then it will be more balanced I think..
We also have support department which borrows developers for support tasks. Sometimes it is difficult to agree what is going or is not going to be done for this or that customer (because support wants it all). For this case R&D manager - a very good idea too..
Ideally, I like the idea going completely lean so that developers don't need a manager or shield...but I don't know whether and how it works...:)
I agree with S. Lott. Short sprints are better. Short user stories can help to. We try to limit our user stories to 2 - 4 days max.
Make sure that all your user stories are well defined and that the owner in agreement with them.
Once a sprint has started, insist that new tasks cannot be added to the current sprint, but they can be high priority in the next sprint. Shorter sprints make this much easier.
Also, in order to remove the imposition of artificial deadlines, you really shouldn't deliver items from the current sprint until the beginning of the next sprint when possible.
The hardest part about agile development is discipline. Once you have a disciplined team and scrum master, the users get used to it and things move much smoother. I'm not sure if you use any software for project management, but take a look at Rally. They have made some major improvements over the past year or so.
The iteration (Sprint in Scrum) scope should not be changed during the iteration. That's why only one iteration is planned at a time. As S. Lott pointed out, the shorter the iteration, the sooner the Product Owner will be able to get new things planned.
The Scrum Master role is to isolate the Team from such pressure and shall say to the Product Owner that new requests have to wait for the next iteration.
Now the Product Owner role is to maximize the value of the work the Team produces, so if there is a new top-priority item, which could not wait for the end of the current iteration, it is still possible to replace items with similar estimate and that have not been started. This should be the exception, not the rule.
An agile team is Consist of Developer, Business analyst ,Tester ,DBA ,Scrum master and Product owner.All are working as one feature based team.
Agile methodology is here to help business to accelerate the faster product development. The product owner can define the priority and change the priority of it. Actually, it is a Scrum team ,who estimate it including (SME, Developer ,designer ,tester…. Everyone).Each team member brings a different perspective on the product and the work required to deliver a user story and one sprint comprises with big and small user story. If Scrum team feels that it can't be done within sprint then it needs to be a divide into the small chunk of the user story and estimate based on the stack trace involved to developed it.
i.e. If Product Owner(PO) want the specific user story need to finish first but if that story included the multiple changes (i.e. Frontend and backend including database) and it can't complete in one sprint , Scrum team can follow below key rules:
Key Elements :
Divide into the sub-user story based on stack track
Estimate each user story related to this
Scrum master should Informed the Product Owner about the timeline to finish this user story based on team current team velocity
Product owner should be mature enough to understand the timeline as it can't be completed within the sprint.
If Still PO has the problem for priority ,He/she can consult the Scrum Master/Coach.
At a glance, Agile is more for helping business but need to take care that it won't overload scrum team . As it is a regular process for iterative development.
发布评论
评论（10）
Scrum 中的职责定义非常明确 - 产品负责人定义积压项目并确定其优先级，开发人员承诺他们在 Sprint 中可以做多少事情。
因此，产品负责人根本没有权力设定估算。 当然，他仍然可以说他在某个特定时间点需要某些东西 - 这就是自然而然的事情。 但是否可以做到这一点仍然由开发人员来决定。 如果不能，他们必须共同研究如何更改范围或采取其他措施来尽可能满足采购订单的需求。
现在，SM 在无法顺利工作的情况下究竟应该如何行动很大程度上取决于具体情况。 不过，我宁愿看到他在 PO 和团队之间促进良好的关系和沟通文化，而不是让他保护团队免受 PO 的影响。
The responsibilities are very clearly defined in Scrum - the Product Owner defines backlog items and prioritizes them, the developers commit on how much they can do in a Sprint.
So, a Product Owner simply has no authority at all to set estimates. Of course he can still say that he needs something to a specific point in time - that simply happens. But it's still the developers who will say whether it can be done. And if it can't, they have to work out together on how to change the scope or whatever else can be done to get the needs of the PO fulfilled as best as possible.
Now, how exactly the SM should act in a situation where this doesn't work smoothly depends a lot on the specific situation. I'd rather see him facilitate a good relationship and communication culture between the PO and the team than have him shield the team from the PO, though.
“必须有关于应该在数据模型等上花费多少时间的指导。”
正确的。 这就是优先级的意义所在。 您定义工作，确定优先顺序。 您根据优先级进行工作。
什么会失控？
在完成任何事情之前重新定义工作？
在工作完成之前重新定义优先级？
解决方案是一样的。 将工作分成更小的部分，以便在有机会进行更改之前先完成一些工作。
如果您的冲刺时间很短（两周），那么就不可能失控。 如果您进行稍微实际一点的 4 周冲刺，那么您遇到麻烦的可能性很小。
"there has to be guidance as to what amount of time should be spent on data model, etc."
Right. That's what prioritization is all about. You define the work, you prioritize. You work according to the priorities.
What can get out of control?
Redefining the work before anything gets done?
Redefining the priorities before the work gets done?
The solution is the same. Break the work into smaller pieces so something gets done before there's an opportunity to make a change.
If you have short (2-week) sprints, it's not possible to be out of control. If you go for slightly more practical 4-week sprints, then you have a small chance of getting into trouble.
产品负责人应该是保护您免受模糊或变化的客户需求影响的人。
产品负责人不得给出估计。
The product owner is supposed to be the one that shields you from ambiguous or varying customer requirements.
The product owner must not give the estimates.
我不认为这是“失控”的问题。
该陈述本身并没有什么本质上的错误。如果您的应用程序被正确抽象，那么您的数据库无论如何都是独立的。UI 首先的主要问题更多是心理上的：非开发人员会认为，如果他们看到屏幕并在事情“变慢”时变得疯狂，那么他们会认为大部分工作已经完成。但是，我认为您真正的问题可能是：
您标记为产品负责人的人不是。拥有产品，因此没有承担足够的责任。
产品是全部，而不仅仅是“功能需求”（借用术语）。坚持认为 PO 不需要试图推迟了解需要完成的幕后工作范围。一旦 PO 开始关注整个范围，那么他们实际上可以成为更广泛的范围的代表。 。
最终，您的 SM 是负责执行流程的人 他们应该这样做。
I don't think it's a question of "out of control".
There is nothing inherently wrong with that statement by itself. If your app is properly abstracted, then your DB is separate anyway. The main problem with UI first is more psychological: The non-devs will assume that most of the work is done if they see screens and go bonkers when things "slow down". However, here's what I think your real problem could be:
The person you have flagged as a Product Owner is not owning the product, and so isn't taking on enough responsibility.
The product is the whole thing, not just the "functional requirements" (to borrow terminology). Your SM needs to have a sit down and be adamant that the PO needs to not try to push off understanding the scope of the behind the scenes work that needs to be accomplished. Once you're PO starts to look at the entire scope, then they can actually be your representative to the broader stakeholder community.
Ultimately, your SM is the one in charge of enforcing process. They should act like it.
我在两家不同的商店使用过敏捷，两次都效果很好。 我不明白任何失控的事情会如何破坏系统。 在冲刺之前，您计划要执行的所有任务并猜测它们将花费多长时间（始终向上舍入）。 然后您就可以计算出在您的冲刺期间大约可以完成多少工作。
大多数商店采用 4 周冲刺，每天 6.5 小时的工作时间。 设置冲刺后，您不会引入新任务，只有潜入冲刺的计划外工作正在修复您要添加的功能中的错误，当然，这应该包含在您的猜测时间中。
如果您想要更具体的答案，您需要定义“失控”的产品负责人的含义。
I've used Agile at two different shops, both times it works well. I don't see how an out of control anything can ruin the system. Before the sprint, you plan all the tasks you will do and guesstimate how long they will take (always round up). Then you can figure out approximately how much work can be done during your sprint.
Most shops use 4 week sprints, and 6.5hrs of workable time a day. When a sprint has been set, you don't introduce new tasks and only unplanned work that creeps into a sprint is fixing bugs in the features you are adding, of course that is suppose to be included in your guesstimate time.
If you want a more specific answer, you need to define what you mean by an "out of control" product owner.
我有两件事要说。
您可能有某种研发经理（不一定是 Scrum Master），但不是产品负责人）。
这个人可以而且应该（我认为）“保护”开发者。
当我们有这样一个人时，我们就处于这种情况，而且效果很好。 例如，他帮助我们处理待办事项中的非功能性内容。
现在我们没有这个人了。 我们的经理是 scrum master。 他在保护我们方面也做得很好。
虽然……这里的问题是通用 scrum master 没有官方权力，所以他不能说“你不会向他们施加如此大的压力”，但如果他看到团队需要帮助，他当然可以而且应该说话。
团队本身和产品负责人也随着时间的推移而发展，他们开始更加关心彼此。 当团队不承诺更多或说“我们现在需要一些时间来处理非功能性的事情”时，产品负责人会理解。
但话又说回来，如果有一个单独的研发经理，其主要职责是照顾开发人员，那当然很好……那么我认为会更加平衡……
我们还有支持部门，可以借用开发人员来执行支持任务。 有时很难就这个或那个客户要做什么或不做什么达成一致（因为支持人员想要这一切）。
对于这种情况，研发经理 - 也是一个非常好的主意。
理想情况下，我喜欢完全精简的想法，以便开发人员不需要经理或盾牌......但我不知道它是否以及如何工作。 ..:)
I have two things to say.
You probably have some kind of R&D manager (that is not necessarily scrum master) and that is not a product owner).
This guy can and should (I think) "protect" developers.
We were in situation when we had such a guy, and it worked pretty well. He helped us with getting non-functional stuff in the backlog for instance.
Now we don't have this guy. Our manager is scrum master. And he does pretty good job protecting us as well.
Though...the problem here is that generic scrum master has no official power, so he cannot say "you are not going to press them this much", but he of course can and should talk if he sees that teem needs help.
The team itself and product owner also evolve with time so that they start to care more of each other. Product owner understands when the team just does not commit to more or says "we need some time for non-functional stuff now".
But then - again - it's nice of course if there's a separate R&D manager whose main responsibility is taking care of developers...then it will be more balanced I think..
We also have support department which borrows developers for support tasks. Sometimes it is difficult to agree what is going or is not going to be done for this or that customer (because support wants it all).
For this case R&D manager - a very good idea too..
Ideally, I like the idea going completely lean so that developers don't need a manager or shield...but I don't know whether and how it works...:)
我同意S.洛特的观点。 短距离冲刺效果更好。 简短的用户故事可以有所帮助。 我们尝试将用户故事限制在最多 2 - 4 天。
确保您的所有用户
故事有明确的定义
业主同意他们的意见。
冲刺开始后，坚持下去
无法添加新任务
当前的冲刺，但他们可以
下一个冲刺的高优先级。
较短的冲刺可以做到这么多
更容易。
此外，为了删除
人为设定最后期限，
你真的不应该交付物品
从当前的冲刺直到
下一个冲刺开始时
可能。
敏捷开发最难的部分是纪律。 一旦你拥有一支纪律严明的团队和 scrum master，用户就会习惯它，事情就会进展得更加顺利。 我不确定您是否使用任何软件进行项目管理，但看看 Rally。 在过去一年左右的时间里，他们取得了一些重大改进。
I agree with S. Lott. Short sprints are better. Short user stories can help to. We try to limit our user stories to 2 - 4 days max.
Make sure that all your user
stories are well defined and that
the owner in agreement with them.
Once a sprint has started, insist
that new tasks cannot be added to
the current sprint, but they can be
high priority in the next sprint.
Shorter sprints make this much
easier.
Also, in order to remove the
imposition of artificial deadlines,
you really shouldn't deliver items
from the current sprint until the
beginning of the next sprint when
possible.
The hardest part about agile development is discipline. Once you have a disciplined team and scrum master, the users get used to it and things move much smoother. I'm not sure if you use any software for project management, but take a look at Rally. They have made some major improvements over the past year or so.
迭代（Scrum 中的 Sprint）范围在迭代期间不应更改。 这就是为什么一次只计划一次迭代的原因。 正如 S. Lott 指出的那样，迭代越短，产品负责人就能越早规划新事物。
Scrum Master 的角色是将团队与此类压力隔离开来，并应告诉产品负责人新请求必须等待下一次迭代。
现在产品负责人的角色是最大化团队生产的工作的价值，因此如果有一个新的最高优先级项目，无法等待当前迭代结束，仍然可以替换项目具有类似的估计和尚未开始。
这应该是例外，而不是规则。
The iteration (Sprint in Scrum) scope should not be changed during the iteration. That's why only one iteration is planned at a time. As S. Lott pointed out, the shorter the iteration, the sooner the Product Owner will be able to get new things planned.
The Scrum Master role is to isolate the Team from such pressure and shall say to the Product Owner that new requests have to wait for the next iteration.
Now the Product Owner role is to maximize the value of the work the Team produces, so if there is a new top-priority item, which could not wait for the end of the current iteration, it is still possible to replace items with similar estimate and that have not been started.
This should be the exception, not the rule.
坚持明确定义的参与规则，那么你（SM）就可以花时间领导你的团队。
Stick with the clearly defined rules of engagement then you(SM) can rather spend the time leading your team.
敏捷团队由开发人员、业务分析师、测试人员、DBA、Scrum 管理员和产品所有者组成。所有人都作为一个基于功能的团队工作。
敏捷方法可以帮助企业加快产品开发速度。 产品所有者可以定义优先级并更改其优先级。 实际上，它是一个 Scrum 团队，估计包括（中小企业、开发人员、设计师、测试人员……每个人）。每个团队成员对产品以及交付用户故事所需的工作都有不同的看法，并且一个 sprint 包含大的内容和小用户故事。 如果 Scrum 团队认为无法在 sprint 内完成，那么需要将其划分为用户故事的一小部分，并根据开发它所涉及的堆栈跟踪进行估计。
即，如果产品负责人（PO）希望特定的用户故事需要首先完成，但如果该故事包含多个更改（即前端和后端，包括数据库）并且无法在一次冲刺中完成，Scrum 团队可以遵循以下关键规则：
关键要素：
根据团队当前的团队速度完成此用户故事
无法在冲刺内完成。
如果Still PO有优先级问题，可以咨询
Scrum 大师/教练。
乍一看，敏捷更多的是帮助业务，但需要注意的是
它不会让 Scrum 团队超载。 由于这是一个常规流程
迭代开发。
An agile team is Consist of Developer, Business analyst ,Tester ,DBA ,Scrum master and Product owner.All are working as one feature based team.
Agile methodology is here to help business to accelerate the faster product development. The product owner can define the priority and change the priority of it. Actually, it is a Scrum team ,who estimate it including (SME, Developer ,designer ,tester…. Everyone).Each team member brings a different perspective on the product and the work required to deliver a user story and one sprint comprises with big and small user story. If Scrum team feels that it can't be done within sprint then it needs to be a divide into the small chunk of the user story and estimate based on the stack trace involved to developed it.
i.e. If Product Owner(PO) want the specific user story need to finish first but if that story included the multiple changes (i.e. Frontend and backend including database) and it can't complete in one sprint , Scrum team can follow below key rules:
Key Elements :
to finish this user story based on team current team velocity
can't be completed within the sprint.
If Still PO has the problem for priority ,He/she can consult the
Scrum Master/Coach.
At a glance, Agile is more for helping business but need to take care that
it won't overload scrum team . As it is a regular process for
iterative development.