Schwaber and Beedle say "roughly four to sixteen hours."
The upper bound is useful. It forces the team to plan, and helps provide daily visibility of progress.
The lower bound is a useful target for most tasks, to avoid the fragility and costs of overspecification. However, occasionally the team may find shorter tasks useful in planning, and is free to include those. There should be no mandated lower bound.
For example, one of our current stories includes a task to send something to another team -- a task that will take 0 hours, but one we want to remember to finish.
The number of tasks in your burndown chart is irrelevant. It's the remaining time that matters. The team should feel free to change the tasks during the sprint, as Schwaber and Beedle note.
On my last assignment we had between 4 and 32 hours per task. We discovered that when we estimated tasks to more than ~32 hours it was because we did not understand what and how to do the task during estimation.
The effect was that the actual implementation time of those tasks varied much more than smaller task. We often also got "stuck" on those tasks or picked the wrong path or had misunderstood the requirements.
Later we learned that when estimated tasks to be that long it was a signal to try to break it down more. If that was not possible we rejected the task and sent it back for further investigation.
Edit It also gives a nice feeling to complete tasks at least a couple of times a week. It also gives rather fast feedback when something does not go as planned. If someone did not complete an 8h task in two days we discussed if the person was stuck on some part, if somebody else had some ideas how to progress or if the estimate was simply wrong from the beginning.
正如其他人所说，任务较短（4-16 小时）也可以为 PO 和团队提供有关项目进度的良好反馈。它们还可以防止团队成员走上“兔子路”，并在业务需要改变时可能不需要的工作上花费大量精力。
拥有许多较小的任务的一个好处是，它可能为 PO 提供空间来更好地确定任务的优先级并优化交付的价值。你会惊讶地发现，大任务中有多少“重要”部分可以被推迟或消除，如果它们是自己的小任务。
Tasks should probably take one-half day to a day, maybe as much as two days sometimes.
Think about it this way: on a more macro level, short iterations promote agility by creating small amounts of value quickly and allowing plans to change as business needs change. On a more micro level, the same is true for tasks. Just like you don't want to spend 3 months on a single iteration, you don't want to spend a week on a single task.
Daily standup meetings can give you a clue that your task size is too big. If team members frequently answer "What did you do yesterday?" and "What will you do today?" with the same answer that they gave the day before, your tasks are probably not small enough.
An example of that would be if a team member regularly answers: "I worked on BigComplexFeatureObject today and will work on it tomorrow" for more than one day in a row, that's a clue that your tasks may be too big. Hopefully, the majority of days a team member will report having completed one task and be about to start another.
Short tasks, 4-16 hours as others have said, also give the PO and team good feedback about project progress. And they prevent team members from going down "rabbit trails" and spending a lot of effort on work that might not be needed if business desires change.
A nice thing about having many smaller tasks is that it potentially gives the PO room to prioritize tasks better and optimize delivered value. You'd be surprised how many "important" parts of big tasks can be postponed or eliminated if they are their own small task.
Generally a good yardstick is that a task is something you do on a given day. This is ideal, which means it's rare. But it does fit nicely into that 4-16 hour estimate (some take half a day, some take two days, etc.) that you gave. Granted, I don't think I've ever spent an entire uninterrupted day on a single task. At the very least, you have to break for the scrum meeting. (At a previous job a day of coding was considered 6 hours to account for overhead.)
I can understand the temptation of management to want to plan every single granular detail. That way they can micro-manage every aspect of it. But in practice that just doesn't work. They may also think that they can then use the task descriptions to somehow generate detailed documentation about the software, essentially skipping that as an actual task itself. Again, doesn't work in reality.
Agile development does call for small work items, but taking it too far defeats the purpose entirely. It ends up becoming a problem of too much up-front planning and having to put in a ton of extra re-planning any time anything changes. At that point it's no longer agile, it's just a series of smaller waterfalls.
I don't think that there is a universal answer to this question that fits every situation. I think that you should try what your collegues are proposing, and after the first sprint or two you evaluate and see if the process needs tweaking to accomodate everyones needs and wishes.
That 4 hour figure sounds like a good minimum to me. I like to think in terms of visible results. We don't have a task per line of code, or a label on a screen, or per refactored utility method surely? But when we get to something that someone else can use, like a public class used by someone else, or a set of fields on a screen that allow some useful action then this sounds like a trackable task to me.
For me the key question is "Do we know we've finished it?" with individual helper functions there's a pretty good chance of refactoring and change, but when I say to my colleage "Here, use this" it either works or it doesn't. The task's completeness can be evaluated.
发布评论
评论（6）
Schwaber 和 Beedle 说“大约四到十六个小时”。
上限很有用。它迫使团队制定计划，并帮助提供每日进度可见性。
对于大多数任务来说，下限是一个有用的目标，可以避免过度指定的脆弱性和成本。然而，有时团队可能会发现较短的任务在规划中很有用，并且可以自由地包含这些任务。不应该有强制的下限。
例如，我们当前的一个故事包括一项向另一个团队发送某些内容的任务 - 该任务将花费 0 小时，但我们希望记住完成该任务。
燃尽图中的任务数量无关紧要。剩下的时间才是最重要的。正如 Schwaber 和 Beedle 指出的那样，团队应该在冲刺期间随意更改任务。
Schwaber and Beedle say "roughly four to sixteen hours."
The upper bound is useful. It forces the team to plan, and helps provide daily visibility of progress.
The lower bound is a useful target for most tasks, to avoid the fragility and costs of overspecification. However, occasionally the team may find shorter tasks useful in planning, and is free to include those. There should be no mandated lower bound.
For example, one of our current stories includes a task to send something to another team -- a task that will take 0 hours, but one we want to remember to finish.
The number of tasks in your burndown chart is irrelevant. It's the remaining time that matters. The team should feel free to change the tasks during the sprint, as Schwaber and Beedle note.
在我上次的任务中，每项任务需要 4 到 32 小时。我们发现，当我们估计任务超过约 32 小时时，这是因为我们在估计期间不了解任务的内容以及如何完成任务。
结果是这些任务的实际执行时间比较小的任务差异更大。我们也经常“卡在”这些任务上，或者选择了错误的路径，或者误解了需求。
后来我们了解到，当估计的任务有那么长时，这是一个尝试将其进一步分解的信号。如果不可能，我们会拒绝该任务并将其发回进行进一步调查。
编辑
每周至少完成几次任务也会给人一种很好的感觉。
当事情没有按计划进行时，它还能提供相当快的反馈。如果有人在两天内没有完成 8 小时的任务，我们会讨论这个人是否被困在某个部分，其他人是否有一些如何进展的想法，或者估计从一开始就是错误的。
On my last assignment we had between 4 and 32 hours per task. We discovered that when we estimated tasks to more than ~32 hours it was because we did not understand what and how to do the task during estimation.
The effect was that the actual implementation time of those tasks varied much more than smaller task. We often also got "stuck" on those tasks or picked the wrong path or had misunderstood the requirements.
Later we learned that when estimated tasks to be that long it was a signal to try to break it down more. If that was not possible we rejected the task and sent it back for further investigation.
Edit
It also gives a nice feeling to complete tasks at least a couple of times a week.
It also gives rather fast feedback when something does not go as planned. If someone did not complete an 8h task in two days we discussed if the person was stuck on some part, if somebody else had some ideas how to progress or if the estimate was simply wrong from the beginning.
任务可能需要半天到一天的时间，有时甚至可能需要两天。
这样想：在更宏观的层面上，短迭代通过快速创造少量价值并允许计划随着业务需求的变化而改变，从而提高敏捷性。从更微观的角度来看，任务也是如此。就像您不想在单次迭代上花费 3 个月一样，您也不想在单个任务上花费一周。
每日站立会议可以让您知道您的任务规模太大。如果团队成员经常回答“你昨天做了什么？”和“你今天要做什么？”与他们前一天给出的答案相同，您的任务可能不够小。
一个例子是，如果团队成员连续超过一天定期回答：“我今天在 BigComplexFeatureObject 上工作，明天将在它上工作”，这表明您的任务可能太大了。希望大多数时候团队成员会报告已完成一项任务并即将开始另一项任务。
正如其他人所说，任务较短（4-16 小时）也可以为 PO 和团队提供有关项目进度的良好反馈。它们还可以防止团队成员走上“兔子路”，并在业务需要改变时可能不需要的工作上花费大量精力。
拥有许多较小的任务的一个好处是，它可能为 PO 提供空间来更好地确定任务的优先级并优化交付的价值。你会惊讶地发现，大任务中有多少“重要”部分可以被推迟或消除，如果它们是自己的小任务。
Tasks should probably take one-half day to a day, maybe as much as two days sometimes.
Think about it this way: on a more macro level, short iterations promote agility by creating small amounts of value quickly and allowing plans to change as business needs change. On a more micro level, the same is true for tasks. Just like you don't want to spend 3 months on a single iteration, you don't want to spend a week on a single task.
Daily standup meetings can give you a clue that your task size is too big. If team members frequently answer "What did you do yesterday?" and "What will you do today?" with the same answer that they gave the day before, your tasks are probably not small enough.
An example of that would be if a team member regularly answers: "I worked on BigComplexFeatureObject today and will work on it tomorrow" for more than one day in a row, that's a clue that your tasks may be too big. Hopefully, the majority of days a team member will report having completed one task and be about to start another.
Short tasks, 4-16 hours as others have said, also give the PO and team good feedback about project progress. And they prevent team members from going down "rabbit trails" and spending a lot of effort on work that might not be needed if business desires change.
A nice thing about having many smaller tasks is that it potentially gives the PO room to prioritize tasks better and optimize delivered value. You'd be surprised how many "important" parts of big tasks can be postponed or eliminated if they are their own small task.
一般来说，一个好的衡量标准是任务是您在某一天所做的事情。这是理想的，这意味着它是罕见的。但它确实非常适合您给出的 4-16 小时估计（有些需要半天，有些需要两天等）。诚然，我认为我从来没有在一项任务上度过一整天不受干扰的情况。至少，你得休息一下去参加 Scrum 会议。 （在以前的工作中，考虑到开销，一天的编码被认为是 6 个小时。）
我可以理解管理层想要计划每一个细节的诱惑。这样他们就可以对每个方面进行微观管理。但实际上这行不通。他们还可能认为他们可以使用任务描述以某种方式生成有关软件的详细文档，基本上将其作为实际任务本身跳过。再说一遍，在现实中行不通。
敏捷开发确实需要小的工作项目，但太过分就完全违背了目的。它最终会成为一个问题：过多的前期规划，并且每当发生任何变化时都必须进行大量额外的重新规划。到那时它就不再敏捷了，它只是一系列较小的瀑布。
Generally a good yardstick is that a task is something you do on a given day. This is ideal, which means it's rare. But it does fit nicely into that 4-16 hour estimate (some take half a day, some take two days, etc.) that you gave. Granted, I don't think I've ever spent an entire uninterrupted day on a single task. At the very least, you have to break for the scrum meeting. (At a previous job a day of coding was considered 6 hours to account for overhead.)
I can understand the temptation of management to want to plan every single granular detail. That way they can micro-manage every aspect of it. But in practice that just doesn't work. They may also think that they can then use the task descriptions to somehow generate detailed documentation about the software, essentially skipping that as an actual task itself. Again, doesn't work in reality.
Agile development does call for small work items, but taking it too far defeats the purpose entirely. It ends up becoming a problem of too much up-front planning and having to put in a ton of extra re-planning any time anything changes. At that point it's no longer agile, it's just a series of smaller waterfalls.
我认为这个问题没有适合所有情况的通用答案。我认为你应该尝试你的同事所建议的，并且在第一个或两个冲刺之后你评估并看看这个过程是否需要调整来满足每个人的需求和愿望。
I don't think that there is a universal answer to this question that fits every situation. I think that you should try what your collegues are proposing, and after the first sprint or two you evaluate and see if the process needs tweaking to accomodate everyones needs and wishes.
对我来说，4 小时这个数字听起来不错。我喜欢从可见结果的角度来思考。我们肯定没有每行代码一个任务，或者屏幕上的标签，或者每个重构的实用方法吗？但是，当我们遇到其他人可以使用的东西时，例如其他人使用的公共类，或者屏幕上允许执行一些有用操作的一组字段，那么这对我来说听起来像是一个可跟踪的任务。
对我来说，关键问题是“我们知道我们已经完成了吗？”对于单独的辅助函数，重构和更改的机会很大，但是当我对我的同事说“在这里，使用这个”时，它要么有效，要么无效。可以评估任务的完成度。
That 4 hour figure sounds like a good minimum to me. I like to think in terms of visible results. We don't have a task per line of code, or a label on a screen, or per refactored utility method surely? But when we get to something that someone else can use, like a public class used by someone else, or a set of fields on a screen that allow some useful action then this sounds like a trackable task to me.
For me the key question is "Do we know we've finished it?" with individual helper functions there's a pretty good chance of refactoring and change, but when I say to my colleage "Here, use this" it either works or it doesn't. The task's completeness can be evaluated.