Tasks are not first class story board citizens.

Posted on March 1, 2012


It should be quite clear from the title that this is case (hint: it’s a story board) but in this blog I aim to argue for what I consider the correct place of tasks in the agile development process. This is an opinionated blog. You don’t have to agree. 🙂

In the last two places I have worked tasks have been put through the full story board life-cycle. Admittedly in one of these cases I encouraged it myself but because of that very experience I have since thought it through properly and come to a different conclusion. In my current place of work tasks are also put all the way through the board and despite my best efforts I have not to succeeded in sharing my realisation that tasks should not be considered equal to stories, the primary citizen on the agile board. This blog aims to record my current thinking and concerns. It’s not a rant. Honest.

Why are tasks not like stories?

Tasks can be anything. Make coffee. Write documentation. Maybe even do some coding. It may be better to first look at was makes a good story to distinguish them from the common task. The INVEST model is often something that gets quoted when this question comes up. Stories that follow this model are typically:

  • Independent
  • Negotiable
  • Valuable
  • Estimatable
  • Sized / Small
  • Testable

While tasks should be some of the above properties (valuable in particular) they shouldn’t have to be all of the above. For example they shouldn’t need to be (and often aren’t) independent or even testable (by a tester, if you code you should unit test, of course). They probably should be small, or at least whatever size is practical for the given situation.

Tasks should have the freedom to be whatever is suitable for making progress in the development of a story. Often tasks are made redundant half way through the story, so you should be allowed to delete them if they are not needed any more or add new ones as they are required. I wouldn’t want anyone to have this amount of freedom with true stories.

Tasks are merely an aid to get the story done. Getting a story done is not about completing a previously agreed number of tasks. It is about meeting the customer expectations of the feature. They do not care that you have completed all your tasks if the feature isn’t quite what they expected. They won’t, importantly, pay.

Task are primarily a developer concern; a way to parallelize or break-down work on a story. It’s fine if they just exist on a post-it stuck to a developers monitor. They are an aid to getting the main job done, the story.

First class tasks may impede refactoring.

Escalating the level of tasks to that of stories may make some developers think of the task as being completely done and it’s implementation set in stone as it has gone all the way through the board. This may discourage them from refactoring the code, particularly if the developer who completed the task is more senior.

Task/Story board correlation.

How do you manage the task/story board correlation when, say, one task is in dev, one in dev check and one in verify? Where does the actual story card go? It needs to be on the board somewhere surely but where? If it stays in backlog or ready column it just looks, at a glance, that the work hasn’t been started yet. It can go in veryify or done or it could track it’s last task but that can just get a bit confusing, especially when tasks get put back into in dev from verify .

Tasks fit awkwardly on the board. I want to avoid this and make the board simple. If one of the benefits of visual story boards is that you can see progress quickly, I don’t see how tasks help with this.

What are tasks good for?

So why do people keep giving tasks such a prominent place in the development process?

Monitoring story progress

Stories can get ‘stuck’ in dev. This can be a problem, especially if the stories are quite large. Yes you may want to be able to see progress by a glance at the board or you could ensure you listen to the developer / pair working on the story at your daily standup. Listening and talking is good. You usually get better information when you talk to people and it doesn’t really take that much time. You could ask people to state what % of the story they are working on is completed. It will be at least as accurate as looking at the number of tasks that have been completed. If a story is taking more than a day it is probably a good idea to give the rest of the team a relative indication of progress in some way. You don’t need first class tasks to do this.

Detailed analysis

Tasks can be useful for eliciting more details analysis of what kind of things typically take a lot of time out of the development process so that that teams can apply training and effort making improvements. For me, this is where I can get actual value out of tasks. To do this tasks need to be categorized. This could be done manually or if you are using an electronic board of some kind you could do this automatically, either by a custom category field or some convention that you can report on. I hate to say it but TFS is fairly useful in this regard particularly (It has other issues though).


Tasks are often used to get more details estimates for stories, e.g. as part of sprint planning. This is ok. It is just estimation. The tasks should help the estimation, not try to conform to INVEST. You don’t necessarily need to keep the same tasks when development starts.

Tasks are valuable sources of information and have many uses, however, all the above can be done even without amplifying tasks to first class board citizens.

Suggested task usage?

I like tasks and I am not suggesting we should get rid of the altogether if we find them useful. I am only suggesting we make them second class boards citizens rather than first. Or rather, citizens of a story rather than the board itself. Apply good OO practises to tasks and encapsulate them within the story and do not allow them to leak outside.

One way to look at it is to create a mini task board within the in dev phase. Each story is really a mini sprint of tasks. Tthe task board would probably just be a list of the tasks and some visual clue of how which have been done. Colours, strike-throughs, whatever.
The tasks could capture information such as start date/time, end date/time, category, description and who it is assigned to, which should allow for quite details analysis without too much effort. A good digital story board would help in this regard as some information could be auto-captured.

If you are using a manual board with cards made from trees you could cut strips of one side of the card for each task and fold them back as they are completed.

Image and video hosting by TinyPic

This way you still get all the benefits, estimation, analysis, reporting, without having to complicate and confuse your board.

Thank you for reading.

Posted in: Agile