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”.
-
We have another problem with this. We have 60 user stories to be implemetned in one iteraiotn, everyone with 5 or 6 tasks… We just simply do not have enough space for all
-
60 stories in one sprint? I’d be interested to know the size of the team and the length of the sprint. Is this normal for your team, and do they always meet such a commitment?
-
Hi Tobias,
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. -
Hi Jose,
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.
-
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…
-
Hi David,
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).
-
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.
10 comments
Comments feed for this article
Trackback link: http://www.xqa.com.ar/visualmanagement/2009/02/one-day-tasks/trackback/