Scrum的会太多了吗？
编按：译者在使用Scrum的历程中，遇到过Scrum会议开得很顺滑的团队，也遇到过挣扎于Scrum会议的团队。对于前者，通过本文可以加深对其中逻辑的理解。对于后者，本文可以帮助您认清障碍，跨越鸿沟。
Myth 11: In Scrum, we spend too much time in meetings
Scrum的会太多了吗？
Barry Overeem
Scrum is intended as a simple, yet sufficient framework for complex product delivery. Scrum is not a one-size-fits-all solution, a silver bullet or a complete methodology. Instead, Scrum provides the minimal boundaries within which teams can self-organize to solve a complex problem using an empirical approach. This simplicity is its greatest strength, but also the source of many misinterpretations and myths surrounding Scrum. In this series of posts we — your ‘mythbusters’ Christiaan Verwijs & Barry Overeem — will address the most common myths and misunderstandings. PS: The great visuals are by Thea Schukken. Check out the previous episodes here (1, 2, 3, 4 , 5, 6, 7, 8, 9 and 10).
Scrum的目的是作为一个简单而又足够的框架来实现复杂的产品交付。Scrum不是一个万能的解决方案，一个银弹或者一个完整的方法。相反，Scrum提供了最小的边界，团队可以自组织地使用经验方法解决一个复杂的问题。这种简单性是它最大的优点，同时也是围绕Scrum的许多误解和迷思的源头。在这一系列的文章中，我们的Barry Overeem和Christiaan Verwijs将会解决最常见的迷思和误解。插图:Thea Schukken。
Myth: In Scrum, we spend too much time in meetings
迷思:在Scrum中，我们在会议上花了太多时间
When Scrum is introduced, Development Teams tend to enthusiastically embrace it. Scrum promotes self-organization, autonomous, multidisciplinary teams and acknowledges individual qualities and contributions to a team effort. Who doesn’t want to be part of a Scrum Team?
Quite often however, after the Scrum honeymoon, people start raising issues:
“Since the introduction of Scrum, all I do is attend meetings. I didn’t become a developer to attend meetings all day long.”
“With Scrum I hoped we would get a team culture, but instead it feels more like a meeting culture.”
“I thought Scrum meetings were time boxed, but our daily Scrum takes at least 30 minutes and afterwards we still don’t have a solid plan as a team.”
These frustrations drive some Scrum Teams to abandon Scrum altogether. Today, we’re going to bust the idea that Scrum is an enabler of a meeting culture. A culture in which Scrum teams are stuck in too many unproductive meetings that prevent them from creating a valuable product for their customers.
当Scrum被引入时，开发团队往往热情地拥抱它。Scrum促进了自我组织、自主、多学科的团队，并承认个人的素质和对团队努力的贡献。谁不想成为Scrum团队的一员?
然而，在Scrum蜜月之后，人们往往会开始提出一些问题。
自从引入Scrum之后，我所做的就是参加会议。都没时间做开发了。
在Scrum中，我希望我们获得团队文化，但感觉更像是一个会议文化。
我认为Scrum会议是时间限制的，但是我们的每日Scrum至少需要30分钟，之后我们仍然没有一个完整的团队计划。
这些挫折促使一些Scrum团队完全放弃Scrum。今天，我们将打破Scrum是会议文化的推动者的理念。在会议文化中，Scrum团队被困在太多低效的会议中，从而无法为他们的客户创造出有价值的产品。
Busting the myth
破解迷思
The Scrum Guide describes five Scrum events (not ‘meetings’) that create regularity and minimize the need for meetings not defined in Scrum. Every event has a clear purpose and plays an important role in the inspect-and-adapt cycle of Scrum. The events are time-boxed, which means they have a maximum duration.
Let’s address two of the issues behind this myth separately:
Factually, how time-consuming are the Scrum events?
Should we spend (this much) time on these events?
Scrum指南描述了创建规律性的5个Scrum事件（不是“会议”），并最小化了在Scrum中没有定义的会议的需要。每个事件都有明确的目的，并且在Scrum的检查和调整周期中扮演着重要的角色。这些事件是有时间限制的，这意味着它们有最长的持续时间。
让我们分别谈谈这个迷思背后的两个问题。
事实上，Scrum事件有多么费时？
我们应该在这些事件上花（这么多）时间吗?
Factually, how time-consuming are the Scrum events?
事实上，Scrum事件有多么费时？
The prescribed time-boxes are based on a sprint of 1 month. For shorter Sprints, the event is generally shorter. The time-boxes are:
Daily Scrum: 15 minutes;
Sprint Planning: at most 8 hours;
Sprint Review: at most 4 hours;
Sprint Retrospective: at most 3 hours;
The activity of refining the Product Backlog requires on average 10% of the capacity of the Development Team. Considering these time-boxes, Scrum doesn’t seem a framework that should result in a meeting culture.
For a full-time developer in a 4-week Sprint, the Scrum events take at most 22,5% of the time:
Full-time: 160 hours per Sprint
Scrum events: 20 hours
Backlog refinement: at most 16 hours
If we visualize the Scrum events for a 2-week Sprint it doesn’t look too bad right?
以下定义的时间盒是以一个月的迭代为基础的。对于较短的迭代，事件会相应更短。时间盒是：
每日站会：15分钟；
迭代计划会：最多8小时；
迭代评审会：最多4小时；
迭代回顾会：最多3小时。
精化产品Backlog的活动需要开发团队平均10%的容量。考虑到这些时间盒，Scrum似乎并不是一个会导致会议文化的框架。
对于一个为期4周的Sprint的全职开发人员来说，Scrum事件最多占到时间的22%。
全部时间：每迭代160小时
Scrum事件：20小时
Backlog精化：最多16小时
如果我们将Scrum事件可视化在一个为期两周的Sprint中，那么它看起来就不那么糟糕了。
Should we spend (this much) time on these events?
我们应该在这些事件上花（这么多）时间吗?
Scrum is built on the observation that software development is a very complex endeavour. As we work together, our understanding of both the problem and the solution grows. This requires collaboration between the people that are doing the work. By bringing in our individual perspective, expertise, creativity and wisdom, we have a better chance of making sense of this complex problem we’re trying to solve. Central to this collaboration are conversations, as Tobias Meyer puts it in his book ‘The People’s Scrum’. Conversations about what has been done, what should be done next and whether or not that actually worked.
Scrum provides a minimal set of boundaries (five events, three roles, three artifacts) to have the appropriate conversations at the appropriate time with the appropriate people. It focusses our conversations on what is important at that point in time, as part of the empirical process of Scrum.
Scrum是建立在对软件开发是一项非常复杂的工作的观察之上的。当我们一起工作时，我们对问题和解决方案的理解都在增长。这需要在做这项工作的人之间进行协作。通过引入我们个人的视角、专业知识、创造力和智慧，我们有更好的机会来理解我们正在试图解决的这个复杂问题。这种合作的核心是对话，正如Tobias Meyer在他的书《人的Scrum》中所说的那样。讨论已经完成的事情，下一步应该做什么，是否应该做。
Scrum提供了一组最小限度的边界（5个事件，3个角色，3个工件），在适当的时间与合适的人进行适当的对话。作为Scrum经验过程的一部分，它把我们的谈话集中在那个时候重要的事情上。
“Scrum provides a minimal set of boundaries (five events, three roles, three artifacts) to have the appropriate conversations at the appropriate time with the appropriate people.”
Spending time on the Scrum events is incredibly valuable as it helps us plan the work, align our work with the problem that we’re trying to solve and to continuously improve our process through timely reflection. Within the complex domain of software development, this is not a luxury but a necessity.
在Scrum事件上花费时间是非常宝贵的，因为它可以帮助我们规划工作，使我们的工作与我们试图解决的问题保持一致，并通过及时的反思不断地改进我们的流程。在软件开发的复杂领域中，这不是一种奢侈，而是一种必要。
The origins of this myth
迷思的起源
So where does this myth come from? We think there are a couple of reasons:
那么这个迷思从何而来呢？我们认为有几个原因。
1. The meeting culture was already there
1. 会议文化本来就有，以及背后的组织功能失调
The visualisation of the 2-week Sprint with the Scrum events probably isn’t the reality for many Scrum Teams. The Scrum Guide states that the Scrum events should be used to create regularity and to minimize the need for meetings not defined in Scrum.
很多Scrum团队做不到以Scrum事件来可视化2周的迭代。Scrum指南指出，Scrum事件应该被用来创建规则，并最小化Scrum中没有定义的会议的需要。
“The Scrum events should be used to minimize the need for meetings not defined in Scrum.”
But Scrum Teams often have to attend meetings outside of the regular Scrum events. For example: company wide presentations, knowledge sharing sessions, progress updates to management, one-on-ones, action review meetings, governance cadence meetings, idea generations meetings, workshops, problem solving sessions, decision making meetings, information gathering meetings, bilaterals with the team manager, introductions, issue resolution meetings, community of practice meetings, training sessions etc. Meetings, meetings, meetings and yet more meetings.
This makes our tidy Sprint schedule a bit more convoluted:
但是Scrum团队经常需要参加常规Scrum事件之外的会议。例如：公司范围的讲座、知识分享会议、向管理层的进展更新、一对一交流、行动检查会议、监管会议、收集想法的会议、研讨会、解决问题的会议、决策会议、信息收集会议、跟经理的会、介绍会、问题解决会议、实践社区会议及培训会议等。没完没了的会。
这使得我们整齐的Sprint日程变得更加复杂：
Are the Scrum events really the problem here, or does Scrum simply make the existing meeting culture transparent? Are all these other meetings really necessary? Or are they merely the result of non-optimal implementations of Scrum, with people being part of multiple teams, teams that are not really cross-functional (and have lots of dependencies) and Product Owners without actual mandate. This is where the role of the Scrum Master becomes important; help identify those meetings that aren’t necessary, and eliminate them from the schedule. Help the organisation find other ways to organize work that aligns better with Scrum, so that the need for additional meetings can be minimized.
Scrum事件真的是这里的问题，还是Scrum仅仅让现有的会议文化变得透明？这些会议真的有必要吗？或者，它们仅仅是Scrum非最优实现的结果，因为人们是多个团队的一部分，不是真正跨职能的团队（并且有很多依赖关系），和产品负责人没有获得实际的授权。这就是Scrum Master的角色变得重要的地方：帮助确定那些不必要的会议，并将它们从时间表中删除，帮助组织找到别的组织工作的方法。
“Are Scrum events really the problem, or does Scrum simply make the existing meeting culture transparent?”
2. Poor facilitation of the Scrum events
2. Scrum事件引导得不好
If we decide to spend time on a Scrum event, it should be facilitated in a way that is respectful of that investment. In reality, most Scrum events are facilitated in a way that is quite boring. The Sprint Review is a lengthy presentation of new features, without opportunities for interaction and exploration. The Sprint Planning has the team sitting around a table for a good four hours, listening to the two people that do most of the talking. The Daily Scrum devolves into in-depth discussions between a handful of people, running up to 30 minutes or more. And because no refinement is done during the Sprint, Sprint Planning tends to drag on and on as work is identified and broken down.
Good facilitation requires focus on the purpose of the event and respect for the time-box. What should we have conversations about? How can we have these conversations in ways that are more effective than just sitting around a table, listening to a couple of people? The role of the facilitator is to keep the conversations on-topic, to create a safe atmosphere and to promote open discussion. Without proper preparation and facilitation the Scrum events will be (and feel like) a waste of time.
如果我们决定把时间花在Scrum事件上，就应该以一种尊重这种投资的方式来促进它。现实中，大多数Scrum事件都是通过一种非常磨人的方式进行的。Sprint评审是冗长的新特性展示，没有交互和探索的机会。迭代计划会议让团队围坐在一张桌子旁整整四个小时，倾听着两个人的谈话。每日Scrum都在少数人之间进行深入的讨论，持续时间达到30分钟甚至更多。而且，由于在Sprint中没有进行产品列表精化，所以Sprint计划往往会因在工作的确定和分解中遇到困难而不断拖延。
好的引导需要关注事件的目的和对时间盒的尊重。我们应该讨论什么? 我们怎么能以比坐在桌旁，听几个人的方式更有效的方式进行对话呢? 主持人的作用是保持谈话的主题，创造一个安全的氛围和促进公开讨论。如果没有适当的准备和引导，Scrum事件将会 (并且感觉) 是在浪费时间。
“Without proper preparation and facilitation the Scrum events will be a waste of time.”
没有适当的准备和引导，Scrum事件将是浪费时间。
3. Part-time team members or people that are part of multiple teams
3. 兼职团队成员/团队成员隶属多个团队
For part-time members of Scrum Teams, the Scrum events will obviously consume a larger part of their workweek. This happens when people are part of multiple teams, or do a lot of work outside of their team. Some people possess a scarce skill that is needed by several Scrum Teams - like database administration or a ‘rockstar’ developer. If that person has to join every Scrum event, it will certainly feel like a 5-headed meeting monster.
Is Scrum really the problem here? Or is Scrum simply surfacing existing organizational dysfunctions - like the idea that putting people in as many teams as possible is ‘more efficient’ or that organizations depend on individuals with critical skills.
对于Scrum团队的兼职成员来说，Scrum事件显然会消耗他们一周工作的大部分时间。当人们是多个团队的一部分，或者在团队之外做大量工作时，这种情况就会发生。有些人拥有一些Scrum团队所需的稀缺技能，比如数据库管理或是明星开发人员。如果那个人必须参加每一个Scrum事件，那看起来就像是一个五个头的会议怪物。
Scrum真的是问题所在吗? 或者Scrum只是呈现出现有的组织功能障碍——比如认为把人放在尽可能多的团队才是效率最大化，或者组织依赖于具有关键技能的个人。
“Is Scrum simply surfacing existing organizational dysfunctions?”
4. ‘Only sitting behind my laptop is work’ (or efficiency over effectiveness)
4. 只有坐在电脑前才是工作（或者认为有效率高于有效果）
In many organizations, there is a strong implicit belief that ‘only sitting behind your laptop is work’. For developers, this is akin to saying that ‘only coding is work’. These beliefs are often reinforced by classifying ‘laptop work’ as billable work, whereas meetings are non-billable. The core assumption here is that we generate value only when sitting behind our laptops, and that we should maximize this time.
The idea that ‘only sitting behind my laptop is work’ is an old-fashioned idea. Product development is not routine work. We frequently need to have conversations about where we stand, to make sense of what is happening and to think about what next step makes sense. These conversations are necessary and valuable. Although it may feel inefficient to spend time with the entire team in a room (‘that’s 3 hours with 6 people; 18 hours of non-billable work!’), it will be more effective in the outcomes that it generates. After all, everyone’s creativity, wisdom and expertise was used to arrive at a shared understanding that is carried by all. We don’t have to spend time after the meeting building consensus, bringing members up-to-speed on what was decided or restarting the conversation as members that didn’t attend bring up good points.
在许多组织中，有一种强烈的隐性信念，那就是只坐在你的笔记本电脑前面才是工作。对于开发人员来说，这类似于说只有编码才是工作。这些信念通常是通过将坐在笔记本前面电脑的工作归类为可计费的工作而得到强化，而认为会议是不能被计费的。这里的核心假设是，只有当我们坐在笔记本电脑前面时，我们才会产生价值，因此我们应该最大化这种工作。
仅仅坐在我的笔记本电脑前面才是工作的想法是过时的想法。产品开发不是例行工作。我们经常需要讨论我们的所知，了解正在发生的事情，并思考下一步该做什么。这些对话是必要和有价值的。尽管花时间和整个团队呆在一个房间里可能会感觉效率低下（3个小时和6个人在一起 -- 18个小时的不能被计费的工作！）但它会让产生的结果更有效。毕竟，每个人的创造力、智慧和专业知识都被用来达到一个目标。
“Although it may feel inefficient to spend time with the entire team in a room, it will be more effective in the outcomes that it generates.”
虽然花时间和整个团队呆在一起可能会让人感觉效率低下，但它会让产生的结果更有效。
Tips
窍门
What can you do to improve the effectiveness of your Scrum Events? How can you make them more enjoyable? Here are some tips, based on our own experiences:
你能做些什么来提高Scrum事件的有效性？你怎样才能使人们更愉快？以下是一些基于我们自身经历的建议。
1. Don’t have meetings. Have workshops that promote conversations
1. 不要开成会议，要开成促进对话的研讨会
‘Meetings’ have the smell of being boring, tedious and energy draining - a group of people sitting around the table waiting for the clock to signal the end of the meeting. Instead, make your Scrum events into something that is fun to do, keeps the energy up and promotes interaction and conversations.
Facilitate the events as workshops rather than meetings. Start with a clear goal and design a series of formats and facilitation techniques that help achieve that goal. Use energizers to keep the energy up and to create a good atmosphere. Allow everyone to be engaged by using a diverge-converge pattern that breaks down large groups into pairs or triplets and have them join up again to share insights. Close the event by asking what stood out for participants; what did they observe? What did they learn? What can be improved to make the event more effective?
会议的气味是无聊、乏味和让人精力耗尽——一群人围坐在桌子旁，等待会议结束的信号。相反，把你的Scrum事件变成有趣的事情，保持活力，促进互动和对话。
将事件作为研讨会，而不是会议。从一个明确的目标开始，设计一系列帮助实现这一目标的格式和便利技巧。要有鼓舞者来让大家保持能量，并创造良好的氛围。采用发散的模式，让每个人都参与，将大的群体分成两人或三人一组，并让他们再次联合起来分享见解。通过询问参与者的立场来结束这一事件; 他们观察了什么呢? 他们学习什么? 有什么可以改进以使事件更有效?
“Facilitate the Scrum events as workshops rather than meetings.”
2. Fit meetings into the schedule of the Development Team
2. 把会议装进开发团队的时间表中
For most managers, attending meetings all day long is pretty much their job. They are used to go from one meeting to another. For a developer this is different. Writing software requires incredible focus and concentration. Having many (ad hoc) meetings throughout the day - even if they’re only a minute - breaks concentration and requires a developer to rebuild this focus. This can take 30 minutes or more, even for experienced developers.
Paul Graham wrote an excellent blog post about this problem in “Maker’s Schedule, Manager’s Schedule”. The Scrum events should already minimize the need for meetings not defined in Scrum. The ones that remain should be planned in such a way that they offer the Development Team as much focus as possible and prevent unnecessary task switching.
对大多数经理来说，整天参加会议几乎是他们的工作。他们习惯于从一个会议到另一个会议。对于开发人员来说，这是不同的。编写软件需要令人难以置信的专注和集中。一整天都有很多（临时的）会议——即使它们仅仅是一分钟的会议，这种打扰也会让开发人员费神重回工作的专注。这可能需要30分钟甚至更长时间，即使对于有经验的开发人员也是如此。
Paul Graham写了一篇关于这个问题的很好的博文：“经理与干活的人的时间表”。Scrum事件应该已经最小化了Scrum中没有定义会议的需要。应该以这样一种方式来计划仍然存在的问题：即尽可能地为开发团队提供专注，并防止不必要的任务切换。
“Having many (ad hoc) meetings throughout the day breaks concentration and requires a developer to rebuild this focus.”
3. Try Liberating Structures
3. 尝试Liberating Structure为Scrum事件增添趣味
Liberating Structures are 33 microstructures that allow you to involve everyone in a group – from extroverted to introverted and from leaders to followers. You can use Liberating Structures to spice up your Scrum events. Move away from the stickies and the whiteboards for a moment, and explore these novel facilitation techniques.
Liberating Structure是33个微观结构，允许你让一个群体中的每一个人参与，从外向到内向，从领导者到追随者。你可以使用Liberating Structure来为你的Scrum活动增添趣味。暂时离开便利贴和白板，探索这些新的引导技巧。
“Use Liberating Structures to spice up your Scrum events.”
4. Respect time-boxes
4. 尊重时间盒，创建专注，减少浪费
The Scrum events offer the opportunity for transparency, inspection and adaptation. These events are time-boxed, such that every event has a maximum duration. Time-boxes create focus and minimize waste. Sticking to the time-box, although the goal of the Scrum event hasn’t been achieved, forces the team to find a solution for the next time. If you don’t respect the time-box, there isn’t a sense of urgency to fix it.
Scrum事件提供了透明、检查和适应的机会。这些事件都是有时间盒的，这样每个事件都有一个最大的持续时间。时间盒创造了专注，减少了浪费。就算Scrum事件的目标还没有实现，但要坚持这个时间盒，这迫使团队在下一次找到解决方案。如果你不尊重时间盒，就没有紧迫感去解决它。
“Time-boxes create focus and minimize waste.”
5. Prepare the Scrum events.
5. 为Scrum事件做准备
As a Scrum Team, reserve time to properly prepare every Scrum event. Agree upon the agenda, structure and desired outcome. For example: what structure do we want to use for the Daily Scrum? Will you use the “three questions” or discuss the Sprint Backlog as a starting point? Hold each other accountable on the shown behaviour. If someone isn’t prepared, it’s the teams responsibility to act on it. A nice tool to help the team understand the purpose and expected outcome of the Scrum events is provided by Crisp with the Agile Meeting Cube.
作为一个Scrum团队，要预留时间适当地准备每个Scrum事件。就议程、结构和期望结果达成一致。例如：我们想在每日Scrum中使用什么结构? 您会使用传统的三个问题或以讨论Sprint Backlog作为一个起点吗? 让每个人对所表现的行为负责。如果一个人没有准备好，那么团队有责任采取行动。帮助团队理解Scrum事件的目的和预期结果的一个很好的工具是由Crisp在Agile Meeting Cube提供的。
“Hold each other accountable on the shown behaviour. If someone isn’t prepared, it’s the teams responsibility to act on it.”
6. Get the most out of the Scrum events
6. 从Scrum事件中受益最多
The Scrum events have clear goals:
Use the Sprint Planning to set a goal for the Sprint and select and identify the work that is needed to achieve that goal;
Use the Sprint Review to gather feedback from stakeholders and (together with them) determine what next steps makes most sense based on what was learned during the Sprint;
Use the Sprint Retrospective to reflect on the past Sprint and identify at least one actionable improvement during the next Sprint;
Use the Daily Scrum to create a daily plan on how the team will work together to achieve the Sprint Goal;
Use Refinement sessions to break down large chunks of work and clarify what might be needed;
If the Scrum events are done in a way to achieve these goals, the need for meetings outside of these events should significantly decrease. Progress updates, action review meetings, idea generations meetings, problem solving, decision making, information gathering; this can all be part of the Scrum events and create space in the Scrum Teams agenda.
If the Scrum Team has to attend a different meeting, they should ask themselves:
Why wasn’t it part of a Scrum event?
How can we make this meeting part of the Scrum events in the future?
Are the Scrum events delivering their intended value?
To allow Development Teams to work with focus and concentration, additional meetings should be aggressively minimized, except for what is necessary to help the team achieve their Sprint Goal. The entire purpose of the Scrum events is to offer a clear cadence, rhythm and focus that prevent unnecessary task switching.
Scrum事件有明确的目的：
使用Sprint计划为Sprint设置一个目标，并选择确定实现该目标所需的工作。
使用Sprint评审来收集涉众的反馈，并(与他们一起)基于在Sprint中所学到的确定下一步的步骤。
使用Sprint回顾来回顾过去的Sprint，并在下一次Sprint中确定至少一个可操作的改进。
使用每日Scrum来创建一个每日计划，关于团队如何一起工作以实现Sprint的目标。
使用精化会议来分解大的工作，并阐明可能需要什么。
如果Scrum事件是为了实现这些目标而进行的，那么在这些事件之外召开会议的需求应该会显著减少。进度更新、行动审查会议、创意会议、解决问题、决策、信息收集；这可以成为Scrum活动的一部分，并在Scrum团队的议程中留出空间。
如果Scrum团队必须参加其他的会议，他们应该问问自己。
为什么它不是Scrum活动的一部分?
我们如何使这个会议成为未来Scrum事件的一部分?
Scrum事件是否能传递了它们（这些其他的会议）的预期价值?
为了让开发团队专注和集中地工作，除了有必要帮助团队实现他们的迭代目标之外，还应该尽量减少额外的会议。Scrum活动的整个目的是提供一个清晰的节奏、韵律和专注，以防止不必要的任务切换。
“The entire purpose of the Scrum events is to offer a clear cadence, rhythm and focus that prevent unnecessary task switching.”
Closing
结论
In this blog post we’ve busted the myth that in Scrum too much time is spend in meetings. We’ve not only described how time-consuming the Scrum events factually are, but also clarified the purpose and importance. After explaining the origins of this myth, we’ve offered some practical tips to prevent or resolve the symptoms.
What do you think about this myth? Do you think in Scrum too much time is spend in meetings? What are your lessons learned?
Want to separate Scrum from the myths? Join our Professional Scrum Master orScrum Master Advanced courses (in Dutch or English). We guarantee a unique, eye-opening experience that is 100% free of PowerPoint, highly interactive and serious-but-fun. Check out our public courses (Dutch) or contact us for in-house or English courses. Check out the previous episodes here (1, 2, 3, 4 , 5, 6, 7, 8, 9and 10).
在这篇博客文章中，我们打破了在Scrum中花费太多时间在会议上的误区。我们不仅描述了Scrum事件的实际耗时，还阐明了它的目的和重要性。在解释了这个迷思的起源之后，我们提供了一些实用的提示来预防或解决这些症状。
你觉得这个迷思怎么样? 你认为在Scrum中过多的时间花在会议上吗? 你学到了什么?
迷思终结者
欢迎加我微信入【真北敏捷】群讨论，接头暗号：真北敏捷。
阅读原文，在线交流。