let’s split the task into N smaller tasks, then estimation error of each smaller task is sqrt(L/N) and its correct length is L/N. simple math will show that estimation error of sum of tasks is sqrt(L) and the mean is L. what does this mean? it means that we gained nothing in terms of precision of task estimation by dividing it into smaller tasks, given that estimation error belongs to Poisson distribution.

what if our ability to estimate difficulty of bigger tasks is the same as smaller ones in relative terms? let’s assume that estimation error belongs to Gaussian distribution, and that ratio of std deviation to mean is the same for larger and smaller tasks: r = sig / L, where sig – std deviation of estimate, L – length of the task. again, we split the longer task into N smaller ones. each small task has L/N length, and sig/N error. if we aggregate the tasks, we get a big task’s mean L, but the error is sig/sqrt(N), i.e. in relative terms we’ve got reduced error or larger task estimation by factor of 1/sqrt(N). what does this mean? it means that if our ability to estimate difficulty of a task in relative terms doesn’t depend on the size of the task, then it’s better to split larger tasks into smaller pieces for project planning purposes given that the error belongs to Gaussian distribution.

if you look at these two examples, then you get a strange feeling that usual arguments for smaller tasks are completely reversed. you better split a task into smaller pieces not when you’re better at estimating smaller task length.

now, let’s add another tweak to the argument – a little bit of behavioral aspect. what if our task effort estimates are not mean? in other words if i think that the task is going to take me 8-10 hours to complete, will i estimate it at 8, 9 or 10? it probably depends on the team spirit, but i bet in most places you’ll get 10 as an estimate, conservative estimate it is.

let’s assume that my estimate will be L+std deviation of error. in other words, in first example my big task estimate would be L+sqrt(L), and my small task estimates would be L/N+sqrt(L/N). aggregating small tasks into a big one we get L+sqrt(LN), in other words i’ll overestimate the big task.

in the second example, i’ll get L+sig for big task estimate, and (L+sig)/N for small task estimates. aggregating small tasks, we get big task estimate of L+sig, i.e. the same mean.

what did we learn now? if the task length estimates are conservative, then splitting larger tasks into smaller ones leads to better precision in effort estimation only if we’re as equally good at effort estimations for smaller or larger tasks. if we estimate smaller task efforts better in relative terms, then by splitting into smaller tasks we may overestimate the task length consistently under certain assumptions.

assumptions are very important, that’s the main point. in this case the assumptions were about effort estimation error distributions. therefore, without experimental study of the distributions, it’s impossible to make recommendations on one-day tasks at least with regards to task effort overestimation issue

]]>I think you should definitively aim for one day tasks if you can and if it is feasible for your team. Tasks of one day seem to be the sweetspot between being able to visualize flow, and keeping granularity as big as possible so as to have the least administrative overhead. Smaller tasks can be a pain to keep track of. For a lot of people it’s just not worth it, and if you can get away without it, there is nothing to lose. But the key issue here is -as you said- not forgetting about stuff because your granularity is too big. Each team has to figure this out for themselves and their situation. The size limits guidelines are: not bigger than one day so as to see flow, and not so small that people start complaining about the administrative overhead (or worse, stop respecting the tasks and updating the board).

]]>Do you see any value in tasks smaller than a day? We tend to task things in hours, more or less, for capacity planning purposes (x developers * 12 dev days / sprint * 6 dev hours / day = y hours), but after seeing a David Anderson kanban talk I’ve been wondering whether the extra granularity’s really adding much. It’s a useful way to make sure you don’t forget anything someone thought of during the planning meeting, but that could just as well be done with sub-task bullet points…

]]>You’ve probably read before that the ideal team size ranges from 5 to 9 people, with a sweetspot in 7. You might want to look into breaking your current team into two sub-teams and making two task boards. As you suggested yourself, I would also work with the Product Owner towards defining larger stories. He must be going crazy keeping track of 60 stories per sprint!

Regardless of how you size your team and your stories, if you ever find yourself having more stories than fit in the board, try to limit the work in progress to the number of stories that actually fit, and as they are finished during the sprint, you put them on the side and pull in a new story into the board. The boards I show in the pictures normally allow for 6 simultaneous stories, which should be more than enough, even for extra-large teams.

]]>Our team is 14 people, and the length of the sprint 3 weeks. Bus stories are quite short, maybe we have to work more on their definition. ]]>

From a business perspective tracking at the story level is even more useful. The story is the smallest unit of business value, and business people should not be concerning themselves with tasks: those are solely in the domain of the development team.

One last point about having few tasks. I find this acceptable if the story is not immediately ready to be worked on. I have worked with teams who prefer to task out in a just-in-time way, and that works in some contexts. I always insist though that each story has at least one task, even if it just says “create tasks”.

]]>