. .

One day tasks – I do not like them anymore

There is a wonderful article about one day tasks that I strongly recommend to read:

One day tasks

February 15, 2009 in Visual management by Xavier Quesada Allue | 8 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.

Read the full article here: One day tasks.

But … I do not agree anymore to this idea. What I discovered in several teams during the last 2 years is that it is much simpler to help people to understand that they need to decompose tasks while they are working on. So a task that gets not done after started within one day, must be broken down into smaller units. And then you start to work on a remaining task of the big old one. Maybe, you will not finish this task, so decompose the task again on the next day until it is completly done.

Avatar of Boris Gloger
„Mut“ ist jener Wert von Scrum, mit dem sich Boris Gloger am stärksten identifiziert. Er hat in seinem eigenen Leben keine Angst vor radikalen Entscheidungen und vor dem Glauben an eine Idee. Für kein Geld der Welt würde er sich Regeln unterwerfen, die keinen Sinn machen. Er glaubt an Scrum, weil es nicht nur bessere Produkte, sondern auch eine bessere und menschlichere Arbeitswelt schaffen kann.
  • http://justanothersoftwareengineer.blogspot.com Kristian Erbou

    In my team we used to split up tasks to oneday-size but it was too rigid and didn’t prove to add value because we could spend a lot of time splitting up tasks to smaller bits instead of – well – just getting some work done, basicly. Now we focus on getting enough tasks to cover every corner of the story we’re working on. If one corner can be documented by a taskcard but solving it will take more than a day – we don’t mind that much because what’s important is that everybody understands which corner of the story the task covers.