One day tasks

February 15, 2009 in Visual management by Xavier Quesada Allue | 9 comments

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.”

BAD: Only one task

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.

GOOD: Lots of tasks

Tags: ,

  1. Tobias Mayer’s avatar

    Tobias Mayer on February 17, 2009 at 5:18 am

    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”.

  2. Joserra’s avatar

    Joserra on February 19, 2009 at 9:05 am

    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 :)

  3. Tobias Mayer’s avatar

    Tobias Mayer on February 21, 2009 at 11:15 am

    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?

  4. Joserra’s avatar

    Joserra on February 22, 2009 at 11:50 pm

    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.

  5. Xavier Quesada Allue’s avatar

    Xavier Quesada Allue on February 23, 2009 at 4:38 pm

    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.

  7. David Moles’s avatar

    David Moles on April 15, 2009 at 12:38 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…

  8. Xavier Quesada Allue’s avatar

    Xavier Quesada Allue on April 15, 2009 at 12:52 pm

    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).