To Task Or Not To Task
I have noticed a trend recently in the Scrum community of de-emphasising, or getting rid of entirely, the concept of Tasks. Teams are encouraged to just run with stories and no finer grained level of detail. I’m not sure this is a good idea. I do have to say here that when I say "tasks", I am not necessarily talking about technical tasks. A task (to me) is something of less than a days duration that needs to be done in order to get the story done. It could be a sub-story, a technical task or a single acceptance criteria, or whatever the team uses to break down the stories into smaller chunks.
One of the arguments for cutting out tasks is that it saves time in sprint planning. One scrum coach told me that “we can cut sprint planning down from 3 hours to just 45 minutes” by essentially cutting out the entire second part of the sprint planning meeting and just work out a list of stories to be done. That implies that the time spent breaking those stories down is waste. I don’t agree.
There are two reasons we break stories down. One is to act as a sort of independent confirmation of our velocity. Break down the stories, estimate the tasks in hours and see whether there are enough hours in the sprint to complete them. I agree that this aspect of tasks is a waste. I’m not a fan of estimation anyway (I will poke that particular hornet’s nest later) and if a team has a stable velocity then their story estimates (or whatever measure they use) is pretty accurate.
The other reason we break stories down though does have value – by breaking a story down into a list of concrete things to do, we force the team to think about how they will implement the story. As a team. The main purpose of that second part of the sprint planning meeting is as a design session where the whole team is present. That’s important. Design work still needs to be done at some point. By not doing it as a team in sprint planning we essentially force the team to do one of three things –
They can hold separate design meetings but in that case all we are doing is trading one meeting for another so I can’t see the benefit. In fact we are trading one meeting for a lot of other smaller meetings each with their attendant inefficiencies (5 minutes to wait for latecomers, 5 minutes to get the projector working…) which is much less efficient.
They can do as most teams do when they go down this path - the design for a story can be done by the developer who picks up that story. Trouble is, that encourages the anti-pattern of “one developer per story” rather than the team working on stories as a team and we now have design being done by an individual rather than a team as well. To me that’s not a smart way to go.
Last, and probably worst, the design becomes part of the story’s “definition of ready” – someone, usually an architect, does the design up front before handing it over to the team. Wow. Two anti patterns for the price of one. We now have individuals doing design and design up front. That’s even less smart than option 2.
My feeling is that the savings gained by cutting out tasks are illusionary. You may save some time in the planning meeting but I suspect that the actual design activities that need to take place anyway will eat up that time and a bunch more due to the inefficiencies and waste associated with it not being a team activity.
There is another reason I like tasks which has nothing to do with planning and everything to do with psychology. A task should be less than a day in size so When you have tasks on a VMB, every day at the standup, people can step forward and move something into the “done” pile. If they don’t it’s a signal that something may be wrong. Unless you slice your stories very fine and make them less than a day as well, if you don’t have tasks, the days standup tends to consist of a bunch of people standing round and saying “Worked on story X yesterday, still working on story X today, no blockers”. There is no sense of progress and no signal (other than the occasional blocker called out) that the story will or won’t be done at the end of the sprint.
One of the key benefits of agile is that we give teams a sense of progress by getting them to deliver every sprint. The VMB is an extension of that – by moving a task every day, they get a sense of progress within the sprint. I find that extremely valuable. It helps maintain energy within the team. It gives them a sense of when the sprint is going well and when it isn’t. Probably the biggest benefit is that moving things to Done feels good. Finishing something is very rewarding.
Agile is all about shortening feedback loops. Removing tasks lengthens the feedback loop within a sprint. That alone is reason to keep them.