Don't be too upset with failing your first sprint. It is rare to do anything 100% the first time. Most first sprints reveal problems that have to be fixed - just as it was in your case.
Your problem has nothing to do with the users / developers ratio. Your problem is properly insulating your sprints and making sure the basic Scrum deal (no scope changes mid-sprint, all scope changes between sprints) is adhered to. Things to do:
Make sure everyone understands Sprint Backlog can't be changed between Sprint Planning and Sprint Review. If anyone tries to force this play by the book: do abnormal termination, throw away all the work work, plan a new sprint and make all of the fuss about it. The reason Scrum calls for this is to make the cost of interruptions and scope changes highly, painfully visible.
Shorten your sprints. Two week sprints worked very well for us because it was pretty easy to explain to any manager type that he can wait 2-3 weeks for his feature. Our PO got pretty good at this eventually.
If for any reason you have short fixes / features that can't wait two weeks institute a "firefighter" - devote one developer per sprint to handling such issues, don't plan any regular work for him. To avoid burnout make it a rotating function - someone is the firefighter each sprint. Hey, you could even buy them a firefighter hat. :)
We did 1 & 2 after our first sprint (way back in 2007) blew just like yours. It helped a lot, so we didn't have to do 3. I advised 3 to a team that had such need and it worked pretty well.
If you allow new requirements during a sprint for this sprint, you're not doing scrum.
The only thing I would allow, are critical bugs in producitve software. These have to be fixed. Here one would allocate one or two devs per sprint who are responsible for bugfixing, if the need arises.
Too many users is not (should not be) a problem. The developer to user ratio depends on the type of the product and the industry/domain, not on the methodology. Small shrinkwrap products (developed by a minimal team, or even a single person) can have millions of users (e.g. Total Commander), while huge internal enterprise products developed by a team of hundreds can have half a dozen users.
The problem is rather that apparently your users are not familiar with Scrum, and you are not using a single product backlog (or haven't taught your users about it).
You should have a single product owner, who decides about what gets into the next sprint, at the start of the sprint. Last minute change requests are (ideally) not allowed - they can only get into the next sprint. It is the product owner's responsibility to communicate with the users, collect and evaluate feature ideas/requests, prioritize them, and OTOH communicate these towards the dev team. In other words, users should never ask features directly from individual developers; they should turn to the product owner instead.
The essence of scrum sprints is that you can't interrupt them with last minute requirements.
Regarding the ratio you are talking about, it depends greatly on what your product is, in which industry you are, and lot of things like that. So to make this value useful, you will have to experiment a bit.
But your developers should rely on your product owner, and not your user base (regardless its size).
Sprint is safe zone. At the beginning of the sprint team discusses product backlog items with product owner and selects subset of these items to be done in upcomming sprint. Team commits to these items. It is team responsibility to deliver commited items so no one can introduce new items during the sprint except the team (this usually happens when items are developed faster than was expected).
Each SCRUM project has to have one Product owner (if there is more than one, there has to be hiearchy) which is responsible for product backlog. If the product owner demands new items during sprint the only way to do it is to cancel current sprint and start the new one.
Possibly a more meaningful ratio would be developers : features/projects. If a manager commits all available resources to a sprint, then there is a higher probability that you'll need to interrupt at least one of them for a critical support issue (for instance); it's a slippery slope to things like "well, you're ahead of schedule, so can you slip this extra functionality in", at which point you've broken one of the core principles behind SCRUM.
I get the feeling you're about to start a campaign for more headcount in your department, to relieve pressures on the current team; perhaps a better long term approach would be to manage expectations of your customers (be they internal or external), so that your existing headcount remains flexible to jump in and handle interruptions; at the same time they can manage expectations that additional requirements get deferred to a later sprint.
One of the biggest mis-conceptions about any Agile methodology is that you can make it up as you go along.
And although this generally true, the key thing is project management and communication.
Like a lot of things in life you can do anything, but there is a consequence. If I buy a Ferrari can I afford to eat?
If I ask for an extra bit of functionality how much is that going to affect the project.
So during planning MoSCoW (Must, Should, Could or Wont) requirements Estimate how long it will take You cannot fill a Sprint / Timebox with Musts or Shoulds
During the sprint / timebox Monitor the time it takes against Estimates Re-plan
When an interruption occurs. Log it and feed this into the Time Taken requirement. Next set of estimates include and interruption factor. Estimation within Agile is an Artform!
When changes are asked for Estimate how long it will take, compare with original estimate Inform the Business User of the effect Prioritise within the MoSCoW
Communication is important. If you want me to add that button there, I will not be able to print the invoice.
Because of MoSCoW it maybe that in sprint 4 the item which is a Wont might make it's way up to a Should or a Must.
Also treat Agile as a toolkit you do not need to prescribe to SCRUM or any other methodology pick the important bits which work for the culture you are in.
发布评论
评论（9）
不要因为第一次冲刺失败而太沮丧。第一次就能100%完成任何事情的情况很少见。大多数第一次冲刺都会暴露出必须解决的问题 - 就像您的情况一样。
您的问题与用户/开发人员比例无关。您的问题是正确隔离您的冲刺并确保遵守基本的 Scrum 协议（冲刺中没有范围更改，冲刺之间的所有范围更改）。要做的事情：
确保每个人都了解Sprint Backlog 无法在 Sprint Planning 和 Sprint Review 之间更改。如果有人试图强制按书本行事：异常终止、扔掉所有工作、计划新的冲刺并为此大惊小怪。 Scrum 要求这样做的原因是为了让中断和范围变更的成本变得非常明显、痛苦。
缩短冲刺。两周的冲刺对我们来说非常有效，因为很容易向任何类型的经理解释他可以等待 2-3 周来获得他的功能。我们的 PO 最终在这方面做得非常好。
如果出于任何原因，您的短期修复/功能等不了两周设立“消防员” - 每个冲刺专门派一名开发人员来处理此类问题，请勿计划任何常规工作为了他。为了避免倦怠，让它成为一个轮换功能——每次冲刺都有一个消防员。嘿，你甚至可以给他们买一顶消防帽。 :)
我们做了 1 & 2 在我们的第一次冲刺（早在 2007 年）之后，就像你的一样。它很有帮助，所以我们不必做 3。我向有这种需求的团队建议了 3，而且效果很好。
Don't be too upset with failing your first sprint. It is rare to do anything 100% the first time. Most first sprints reveal problems that have to be fixed - just as it was in your case.
Your problem has nothing to do with the users / developers ratio. Your problem is properly insulating your sprints and making sure the basic Scrum deal (no scope changes mid-sprint, all scope changes between sprints) is adhered to. Things to do:
Make sure everyone understands Sprint Backlog can't be changed between Sprint Planning and Sprint Review. If anyone tries to force this play by the book: do abnormal termination, throw away all the work work, plan a new sprint and make all of the fuss about it. The reason Scrum calls for this is to make the cost of interruptions and scope changes highly, painfully visible.
Shorten your sprints. Two week sprints worked very well for us because it was pretty easy to explain to any manager type that he can wait 2-3 weeks for his feature. Our PO got pretty good at this eventually.
If for any reason you have short fixes / features that can't wait two weeks institute a "firefighter" - devote one developer per sprint to handling such issues, don't plan any regular work for him. To avoid burnout make it a rotating function - someone is the firefighter each sprint. Hey, you could even buy them a firefighter hat. :)
We did 1 & 2 after our first sprint (way back in 2007) blew just like yours. It helped a lot, so we didn't have to do 3. I advised 3 to a team that had such need and it worked pretty well.
如果您在本次冲刺期间允许新需求，您就没有进行 Scrum。
我唯一允许的就是生产软件中的严重错误。这些必须得到解决。如果需要的话，每个冲刺会分配一到两名开发人员负责错误修复。
If you allow new requirements during a sprint for this sprint, you're not doing scrum.
The only thing I would allow, are critical bugs in producitve software. These have to be fixed. Here one would allocate one or two devs per sprint who are responsible for bugfixing, if the need arises.
用户太多不是（不应该）成为问题。开发者与用户的比例取决于产品的类型和行业/领域，而不是方法论。小型收缩包装产品（由最小的团队，甚至一个人开发）可以拥有数百万用户（例如Total Commander），而由数百人团队开发的大型内部企业产品可以拥有六个用户。
问题在于，显然您的用户不熟悉 Scrum，并且您没有使用单一产品积压（或者没有向您的用户传授它）。
您应该有一个单一产品负责人，由他在冲刺开始时决定下一个冲刺的内容。 （理想情况下）不允许最后一刻的变更请求 - 它们只能进入下一个冲刺。产品所有者有责任与用户沟通，收集和评估功能想法/请求，确定它们的优先级，然后 OTOH 将这些内容传达给开发团队。换句话说，用户永远不应该直接向个人开发人员询问功能；他们应该求助于产品负责人。
Too many users is not (should not be) a problem. The developer to user ratio depends on the type of the product and the industry/domain, not on the methodology. Small shrinkwrap products (developed by a minimal team, or even a single person) can have millions of users (e.g. Total Commander), while huge internal enterprise products developed by a team of hundreds can have half a dozen users.
The problem is rather that apparently your users are not familiar with Scrum, and you are not using a single product backlog (or haven't taught your users about it).
You should have a single product owner, who decides about what gets into the next sprint, at the start of the sprint. Last minute change requests are (ideally) not allowed - they can only get into the next sprint. It is the product owner's responsibility to communicate with the users, collect and evaluate feature ideas/requests, prioritize them, and OTOH communicate these towards the dev team. In other words, users should never ask features directly from individual developers; they should turn to the product owner instead.
scrum 冲刺的本质是你不能用最后一刻的要求打断它们。
至于你所说的比率，很大程度上取决于你的产品是什么，你属于哪个行业，等等。因此，要使该值有用，您必须进行一些试验。
但您的开发人员应该依赖您的产品所有者，而不是您的用户群（无论其规模如何）。
The essence of scrum sprints is that you can't interrupt them with last minute requirements.
Regarding the ratio you are talking about, it depends greatly on what your product is, in which industry you are, and lot of things like that. So to make this value useful, you will have to experiment a bit.
But your developers should rely on your product owner, and not your user base (regardless its size).
Sprint 是安全区。在冲刺开始时，团队与产品负责人讨论产品积压项目，并选择这些项目的子集在即将到来的冲刺中完成。团队致力于这些项目。交付承诺的项目是团队的责任，因此除了团队之外，没有人可以在冲刺期间引入新项目（当项目的开发速度快于预期时，通常会发生这种情况）。
每个 SCRUM 项目必须有一名产品负责人（如果有多于一名，则必须有层次结构），负责产品积压工作。如果产品负责人在冲刺期间需要新项目，唯一的方法是取消当前的冲刺并开始新的冲刺。
Sprint is safe zone. At the beginning of the sprint team discusses product backlog items with product owner and selects subset of these items to be done in upcomming sprint. Team commits to these items. It is team responsibility to deliver commited items so no one can introduce new items during the sprint except the team (this usually happens when items are developed faster than was expected).
Each SCRUM project has to have one Product owner (if there is more than one, there has to be hiearchy) which is responsible for product backlog. If the product owner demands new items during sprint the only way to do it is to cancel current sprint and start the new one.
可能更有意义的比率是
开发人员：功能/项目。如果经理将所有可用资源投入到冲刺中，那么您很有可能需要因关键支持问题（例如）而中断至少其中一个资源；这是一个滑坡，类似于“好吧，你比计划提前了，所以你能把这个额外的功能放进去吗”，此时你已经打破了 SCRUM 背后的核心原则之一。我感觉你即将发起一场活动，要求部门增加人员数量，以减轻现有团队的压力；也许更好的长期方法是管理客户的期望（无论是内部客户还是外部客户），以便您现有的员工人数保持灵活，可以介入并处理中断；同时，他们可以管理将额外需求推迟到以后的冲刺的期望。
Possibly a more meaningful ratio would be
developers : features/projects. If a manager commits all available resources to a sprint, then there is a higher probability that you'll need to interrupt at least one of them for a critical support issue (for instance); it's a slippery slope to things like "well, you're ahead of schedule, so can you slip this extra functionality in", at which point you've broken one of the core principles behind SCRUM.I get the feeling you're about to start a campaign for more headcount in your department, to relieve pressures on the current team; perhaps a better long term approach would be to manage expectations of your customers (be they internal or external), so that your existing headcount remains flexible to jump in and handle interruptions; at the same time they can manage expectations that additional requirements get deferred to a later sprint.
我可能会因此而遭到否决，但我认为这基本上无关紧要。
有一些很棒的产品是由几个人开发的，为数百万用户提供服务。
正如有些项目是由巨大的打击力量开发的，但从未跨过平庸的门槛。
I'll probably get downvoted for that but I think it is largely irrelevant.
There are fantastic products built by a couple of guys serving millions of users.
Just as there are projects developed by a huge strike force which never crossed the threshold of mediocrity.
用户人数/开发人员人数不是相关指标。
您可以让一个用户生成大量更改，而数百个用户则不生成任何（或很少）更改。
相关的是所请求的变更量以及如何管理和跟踪变更。
如果您能够展示需求发生了多少变化，，同时仍然针对其他需求进行实施和设计，您将获得素材。
User head count / dev head count is not a relevant metric.
You can have a single user that generates huge amounts of change versus hundreds that don't generate any (of very little) change.
What is relevant is the amount of change being requested and how it is managed and tracked.
If you can show how much the requirements have changed while still implementing and designing for other requirements you will have your fodder.
关于任何敏捷方法的最大误解之一是，您可以边做边弥补。
尽管这通常是正确的，但关键是项目管理和沟通。
就像生活中的许多事情一样，你可以做任何事情，但都会有一个后果。如果我买了一辆法拉利我能吃得起饭吗？
如果我要求额外的功能，这会对项目产生多大影响。
所以在计划的时候
MoSCoW（必须、应该、可以或不会）要求
估计需要多长时间
在冲刺/时间范围内，您不能用“必须”或“应该”来填充
冲刺/时间 范围
根据预估监控所需时间
重新计划
发生中断时 。记录下来并将其输入到“所用时间”要求中。下一组估计包括中断因素。敏捷中的估计是一种艺术形式！
当要求更改时
估计需要多长时间，与原来的估计进行比较
将影响告知业务用户
在莫斯科内部优先考虑
沟通很重要。如果您希望我在那里添加该按钮，我将无法打印发票。
由于 MoSCoW，也许在 sprint 4 中，“不会”的项目可能会成为“应该”或“必须”。
还将敏捷视为一个工具包，您无需指定 SCRUM 或任何其他方法论，选择适合您所在文化的重要部分。
One of the biggest mis-conceptions about any Agile methodology is that you can make it up as you go along.
And although this generally true, the key thing is project management and communication.
Like a lot of things in life you can do anything, but there is a consequence. If I buy a Ferrari can I afford to eat?
If I ask for an extra bit of functionality how much is that going to affect the project.
So during planning
MoSCoW (Must, Should, Could or Wont) requirements
Estimate how long it will take
You cannot fill a Sprint / Timebox with Musts or Shoulds
During the sprint / timebox
Monitor the time it takes against Estimates
Re-plan
When an interruption occurs. Log it and feed this into the Time Taken requirement. Next set of estimates include and interruption factor. Estimation within Agile is an Artform!
When changes are asked for
Estimate how long it will take, compare with original estimate
Inform the Business User of the effect
Prioritise within the MoSCoW
Communication is important. If you want me to add that button there, I will not be able to print the invoice.
Because of MoSCoW it maybe that in sprint 4 the item which is a Wont might make it's way up to a Should or a Must.
Also treat Agile as a toolkit you do not need to prescribe to SCRUM or any other methodology pick the important bits which work for the culture you are in.