In my opinion, "tasks" don't really belong to the Product Backlog, Product Backlog Items (PBI) should be used for things that are visible to the end users - or mandatory to achieve such items - and expressed in a way that demonstrate their business value.
Recurrent events like meetings, administrative tasks, etc don't really match this definition of a PBI and I wouldn't include them at the Product Backlog level. Actually, I don't see the point of tracking them at all (it sounds like useless overhead i.e. typically waste) and I would thus simply include them in the overall velocity. It just works.
Non recurring events, like a special meeting, R&D, exploration, etc don't really belong to the PB neither (how should a PO value them and prioritize them??) and I prefer to include their "cost" in the estimation of the related PBI. And when the item gets picked, we create a corresponding task in the Sprint Backlog, with a timeboxed estimation.
And we handle trainings like holidays. If a team member go to some training, it affects the team member allocation (e.g. 90%) and thus the overall team capacity calculated at the beginning of a Sprint. And we pick up less items.
我认为您永远不应该在 Spring Backlog 中创建会议、演示等任务。为什么？因为每个任务都有一些影响当前冲刺的估计。在冲刺期间，任务实时完成，并根据燃尽图显示团队在交付客户价值方面的进度。客户将从会议中获得什么价值？此外，此类任务可能与具体的用户故事无关，那么在产品燃尽图中可以看到哪些进展？当您必须计算不包含在用户故事复杂性（故事点）中的价值时，您如何决定下一个冲刺应采用多少个用户故事？
Task is not related to product backlog. Task is related to sprint backlog. Activities you described are not tasks.
When we plan our next sprint we always reduce planned capacity by all holidays and trainings. We also reduce capacity by "administrative overhead". In our case administrative overhead is usually 1MD per team member per week. This overhead is for meetings and possilbe assistance in maintainance on already deployed projects.
Edit:
I think you should never create tasks for meetings, presentations, etc. in your spring backlog. Why? Because each task has some estimation wich affects current sprint. During sprint tasks are completed within real time and based on that burndown chart shows team progress in delivering customer value. What value will customer receive from meeting? Moreover such task is probably not related to concrete user story so what progress will be visible in product burndown chart? How you decide how many user stories should be taken for the next sprint when you have to count with value not included in their complexity (story points)?
Adding such dummy tasks (tasks with no added value) to your sprint backlog will also affect your velocity. It will look like each story point costs more than in reality because meetings time will be included in real work.
What type of meetings do you want to add to your sprint backlog? SCRUM needs only few meetings - daily meeting, planning meeting, review meeting, retrospective meeting and in larger project SCRUM of SCRUM. Daily meeting is so short that it doesn't have to be included in planning. Planning meeting, review meeting and retrospective meeting don't have to be included in sprint. SCRUM of SCRUM is specific and it doesn't affect whole team - can be reduced from planned capacity of attending members. No more meetings are needed. Most important: Communication needed for completing task is part of task estimate.
If you need other meetings simply reduce your capacity. If the customer, management or Product owner complain about small capacity simply explain them that it is because of non standard administrative or bureaucracy overhead.
On my last project we side stepped some activities in to our scrum board. They were not in the product backlog, but we invented them during our planning game.
The kind of activities we included was customer workshops, release activities, etc.
The reason we included them on our scrum board was to make it visible to anyone in the team what everyone else was doing, and in some cases also to assign the task to someone not in the middle of another critical task.
Typical recurrent tasks are absorbed by the estimation/velocity. Things like the stand up meeting, normal developer's interactions, pauses, etc...
For others events that are not related to building the product, I prefer to remove that time from the developer's availability to have the correct capacity.
So the number of user stories that we can plan depend on, their estimation, the team velocity and of course the capacity
My opinion is if these tasks are not directly related to a feature, like training, you should not include them in your product backlog, but rather adjust the available time from developers and consequently the velocity of your iterations. It is not because you have for instance a 40 hours working week that you can expect people to work 40 hours on projects.
If meetings or other non-development tasks are directly associated with achieving the objectives of the sprint\iteration\project then I have no problem including them the sprint backlog\iteration plan. If nothing else it helps to ensure that the tasks get done by raising their visibility.
If you don't include things that people need to do in your backlog, how would you propose to manage them?
Non-development initiatives take time, and they are just as important to delivering a quality product as dev and qa work.
You can choose to use a separate backlog for those items, or carry them in a separate project plan, but then you are working from two working backlogs, and sequencing and timing becomes an issue.
I typically force the teams to create stories for non-development activities like 'as a product manager, I need to produce a roadmap, or 'as a product manager, I need to setup technical workshops to review the backlog so that development teams can understand the features'.
it really depends on the situation, but if the backlog is THE central place to capture and manage work, why is it only Development and QA work that it gets used for?
Scrum 中没有确定用户故事的固定公式。在我的项目中，我们选择应将哪个工作项转换为故事。例如，比较 2-3 个 IDE 开发工具之类的任务会放在 Backlog 中，因为它与开发直接相关。但除此之外，我计划为每个团队成员每天进行 5 小时的开发活动，以便他们将剩余的时间用于参加培训、文档、知识交流、同行编程等。这对我来说可以证明演示与冲刺速度的合理性。
There is no fix formula for deciding User Stories in Scrum. In my project, we pick and choose which work item should be converted to Stories. E.g. tasks like comparison of 2-3 IDE dev tools goes in a Backlog because it is directly related to development. But otherwise I plan for 5 hrs per day development activity for each team member so that they spend remaining hours in attending training, documentation, knowledge exchange, peer programming, etc. This works for me in justifying demo vs sprint velocity.
You can manage non-development tasks in a Trello board. These can be things like research activities or pulling data to be used for development. These don't belong in JIRA or Rally as they are not development tasks and do not have a story point estimation.
发布评论
评论（9）
在我看来，“任务”并不真正属于产品待办事项列表，产品待办事项列表项目（PBI）应该用于最终用户可见的事情 - 或者强制实现这些项目 - 并以证明的方式表达他们的商业价值。
会议、管理任务等重复事件并不真正符合 PBI 的定义，我不会将它们包含在产品待办事项级别中。实际上，我根本不认为跟踪它们有什么意义（这听起来像是无用的开销，即通常是浪费），因此我只是将它们包含在总体速度中。它就是有效的。
非重复性事件，如特别会议、研发、探索等，也不真正属于 PB（PO 应该如何评估它们并确定它们的优先级？？），我更喜欢在估算中包含它们的“成本”相关的 PBI。当项目被挑选时，我们会在 Sprint Backlog 中创建相应的任务，并进行时间盒估计。
我们像对待假期一样对待培训。如果团队成员参加一些培训，则会影响团队成员的分配（例如 90%），从而影响 Sprint 开始时计算的团队整体能力。我们拿起的物品也减少了。
In my opinion, "tasks" don't really belong to the Product Backlog, Product Backlog Items (PBI) should be used for things that are visible to the end users - or mandatory to achieve such items - and expressed in a way that demonstrate their business value.
Recurrent events like meetings, administrative tasks, etc don't really match this definition of a PBI and I wouldn't include them at the Product Backlog level. Actually, I don't see the point of tracking them at all (it sounds like useless overhead i.e. typically waste) and I would thus simply include them in the overall velocity. It just works.
Non recurring events, like a special meeting, R&D, exploration, etc don't really belong to the PB neither (how should a PO value them and prioritize them??) and I prefer to include their "cost" in the estimation of the related PBI. And when the item gets picked, we create a corresponding task in the Sprint Backlog, with a timeboxed estimation.
And we handle trainings like holidays. If a team member go to some training, it affects the team member allocation (e.g. 90%) and thus the overall team capacity calculated at the beginning of a Sprint. And we pick up less items.
任务与产品积压无关。任务与冲刺待办事项相关。您描述的活动不是任务。
当我们计划下一个冲刺时，我们总是通过所有假期和培训来减少计划容量。我们还通过“管理开销”来减少容量。在我们的例子中，管理费用通常是每个团队成员每周 1MD。该开销用于会议以及可能协助维护已部署的项目。
编辑：
我认为您永远不应该在 Spring Backlog 中创建会议、演示等任务。为什么？因为每个任务都有一些影响当前冲刺的估计。在冲刺期间，任务实时完成，并根据燃尽图显示团队在交付客户价值方面的进度。客户将从会议中获得什么价值？此外，此类任务可能与具体的用户故事无关，那么在产品燃尽图中可以看到哪些进展？当您必须计算不包含在用户故事复杂性（故事点）中的价值时，您如何决定下一个冲刺应采用多少个用户故事？
将此类虚拟任务（没有附加值的任务）添加到您的冲刺待办事项中也会影响您的速度。看起来每个故事点的成本都比实际要高，因为会议时间将包含在实际工作中。
您想将什么类型的会议添加到冲刺待办事项列表中？ SCRUM只需要很少的会议——日常会议、计划会议、评审会议、回顾会议以及在较大项目中的SCRUM SCRUM。每日会议的时间很短，因此不必包含在计划中。计划会议、评审会议和回顾会议不一定包含在冲刺中。 SCRUM 的 SCRUM 是特定的，它不会影响整个团队 - 可以从参加成员的计划容量中减少。不需要再开会了。 最重要：完成任务所需的沟通是任务评估的一部分。
如果您需要其他会议，只需减少容量即可。如果客户、管理层或产品所有者抱怨容量小，只需向他们解释这是因为非标准的管理或官僚机构开销。
Task is not related to product backlog. Task is related to sprint backlog. Activities you described are not tasks.
When we plan our next sprint we always reduce planned capacity by all holidays and trainings. We also reduce capacity by "administrative overhead". In our case administrative overhead is usually 1MD per team member per week. This overhead is for meetings and possilbe assistance in maintainance on already deployed projects.
Edit:
I think you should never create tasks for meetings, presentations, etc. in your spring backlog. Why? Because each task has some estimation wich affects current sprint. During sprint tasks are completed within real time and based on that burndown chart shows team progress in delivering customer value. What value will customer receive from meeting? Moreover such task is probably not related to concrete user story so what progress will be visible in product burndown chart? How you decide how many user stories should be taken for the next sprint when you have to count with value not included in their complexity (story points)?
Adding such dummy tasks (tasks with no added value) to your sprint backlog will also affect your velocity. It will look like each story point costs more than in reality because meetings time will be included in real work.
What type of meetings do you want to add to your sprint backlog? SCRUM needs only few meetings - daily meeting, planning meeting, review meeting, retrospective meeting and in larger project SCRUM of SCRUM. Daily meeting is so short that it doesn't have to be included in planning. Planning meeting, review meeting and retrospective meeting don't have to be included in sprint. SCRUM of SCRUM is specific and it doesn't affect whole team - can be reduced from planned capacity of attending members. No more meetings are needed. Most important: Communication needed for completing task is part of task estimate.
If you need other meetings simply reduce your capacity. If the customer, management or Product owner complain about small capacity simply explain them that it is because of non standard administrative or bureaucracy overhead.
在我的上一个项目中，我们将一些活动加入了 Scrum 板。它们并不在产品积压中，但我们在计划游戏中发明了它们。
我们包含的活动类型是客户研讨会、发布活动等。
我们将它们包含在 Scrum 板上的原因是让团队中的任何人都可以看到其他人在做什么，并且在某些情况下还可以将任务分配给不在执行另一项关键任务的人。
On my last project we side stepped some activities in to our scrum board. They were not in the product backlog, but we invented them during our planning game.
The kind of activities we included was customer workshops, release activities, etc.
The reason we included them on our scrum board was to make it visible to anyone in the team what everyone else was doing, and in some cases also to assign the task to someone not in the middle of another critical task.
典型的循环任务由估计/速度吸收。诸如站立会议、正常开发人员的互动、暂停等之类的事情......
对于与构建产品无关的其他事件，我更愿意从开发人员的可用性中删除该时间以获得正确的能力。
因此，我们可以规划的用户故事数量取决于它们的估计、团队速度，当然还有容量
Typical recurrent tasks are absorbed by the estimation/velocity. Things like the stand up meeting, normal developer's interactions, pauses, etc...
For others events that are not related to building the product, I prefer to remove that time from the developer's availability to have the correct capacity.
So the number of user stories that we can plan depend on, their estimation, the team velocity and of course the capacity
我的观点是，如果这些任务与培训等功能不直接相关，那么您不应该将它们包含在产品待办事项中，而应该调整开发人员的可用时间，从而调整迭代的速度。例如，并不是因为每周工作 40 小时，就可以期望人们在项目上工作 40 小时。
My opinion is if these tasks are not directly related to a feature, like training, you should not include them in your product backlog, but rather adjust the available time from developers and consequently the velocity of your iterations. It is not because you have for instance a 40 hours working week that you can expect people to work 40 hours on projects.
如果会议或其他非开发任务与实现冲刺\迭代\项目的目标直接相关，那么我将它们包括在冲刺待办事项\迭代计划中没有问题。如果不出意外的话，它有助于通过提高可见性来确保任务的完成。
If meetings or other non-development tasks are directly associated with achieving the objectives of the sprint\iteration\project then I have no problem including them the sprint backlog\iteration plan. If nothing else it helps to ensure that the tasks get done by raising their visibility.
如果您没有将人们需要做的事情纳入您的积压工作中，您将如何管理它们？
非开发举措需要时间，它们对于交付优质产品与开发和质量保证工作同样重要。
您可以选择对这些项目使用单独的积压工作，或者将它们放在单独的项目计划中，但随后您将处理两个工作积压工作，排序和时间安排就成为问题。
我通常会强迫团队为非开发活动创建故事，例如“作为产品经理，我需要制定路线图，或者“作为产品经理，我需要设立技术研讨会来审查积压工作，以便开发团队能够理解”的特点'。
这确实取决于具体情况，但如果积压工作是捕获和管理工作的中心位置，为什么它只用于开发和质量保证工作？
If you don't include things that people need to do in your backlog, how would you propose to manage them?
Non-development initiatives take time, and they are just as important to delivering a quality product as dev and qa work.
You can choose to use a separate backlog for those items, or carry them in a separate project plan, but then you are working from two working backlogs, and sequencing and timing becomes an issue.
I typically force the teams to create stories for non-development activities like 'as a product manager, I need to produce a roadmap, or 'as a product manager, I need to setup technical workshops to review the backlog so that development teams can understand the features'.
it really depends on the situation, but if the backlog is THE central place to capture and manage work, why is it only Development and QA work that it gets used for?
Scrum 中没有确定用户故事的固定公式。在我的项目中，我们选择应将哪个工作项转换为故事。例如，比较 2-3 个 IDE 开发工具之类的任务会放在 Backlog 中，因为它与开发直接相关。但除此之外，我计划为每个团队成员每天进行 5 小时的开发活动，以便他们将剩余的时间用于参加培训、文档、知识交流、同行编程等。这对我来说可以证明演示与冲刺速度的合理性。
There is no fix formula for deciding User Stories in Scrum. In my project, we pick and choose which work item should be converted to Stories. E.g. tasks like comparison of 2-3 IDE dev tools goes in a Backlog because it is directly related to development. But otherwise I plan for 5 hrs per day development activity for each team member so that they spend remaining hours in attending training, documentation, knowledge exchange, peer programming, etc. This works for me in justifying demo vs sprint velocity.
您可以在 Trello 看板中管理非开发任务。这些可以是研究活动或提取用于开发的数据之类的事情。这些不属于 JIRA 或 Rally，因为它们不是开发任务，也没有故事点估计。
You can manage non-development tasks in a Trello board. These can be things like research activities or pulling data to be used for development. These don't belong in JIRA or Rally as they are not development tasks and do not have a story point estimation.