One day tasks are tasks that take -in theory- up to one day to complete by one person, or by a pair of people in the case of pair programming. Creating tasks of one day maximum size gives two benefits to the team. The first is that under normal conditions it creates visible daily flow. Meaning that if nothing goes wrong, one task will be finished (on average) per team member per day. So if a team has 8 members, theoretically they should finish 8 tasks per day. But in Agile teams, people work in pairs a lot, either pair programming, or a coder/analyst-tester pair, so in practice it should be around half of that that gets finished. And effectively, my experience is that in healthy 8-member teams, you should expect to see around 4 DONE tags per day.
Without one day tasks, you will end up with a story with only one or two Post-its, where nothing ever moves and during the daily Scrum a team member says “I’m still working on this… yep… still some work to do, still working on it.”
The other advantage of having one-day tasks is that it is great way to see if the team has really analyzed the story or not. Sprint planning blues? Having one day tasks forces the team to think about what they really have to do to finish that story, to a good level of granularity that is later on easy to follow up. The big effort is not in writing the Post-its, it’s in thinking what has to be done in those 1-day chunks.
I am an advocate of tasks being one day or less. Often times they are much smaller, so in my experience a team gets around 5-20 tasks done per day. As you say the visual flow is important, and stagnant boards provide no useful information. Keeping tasks small also means we can avoid the Scrum-suggested concept of tracking hours, which to my mind borders on micro-management. Tracking at the task level is much more useful. And simpler. A task is done or not done. It is binary.
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”.
Pingback from Visual Management Blog · The DONE tag on March 9, 2009 at 8:14 pm
Hey, Xavier —
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…
Pingback from One day tasks - I do not like anymore on August 21, 2009 at 3:53 pm
let’s say my ability to estimate the task’s difficulty/length in hours is inversely proportional to the length of a task, i.e. longer is the task – harder to estimate its correct length. in this case we could assume that estimation error is from Poisson distribution: if L – correct length of a task, then estimation error’s std deviation is sqrt(L).
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
You must be logged in to post a comment.
Comments feed for this article
Trackback link: http://www.xqa.com.ar/visualmanagement/2009/02/one-day-tasks/trackback/