Task Tracking Is an Agile Smell

We’re looking at tools to help manage agile projects. This is a large, globally distributed enterprise, and that’s not going to change, so I suppose some sort of expensive tool is a necessary evil.

Many people are involved with reviewing the tools (which include things like Mingle, ScrumWorks, Agile on Demand, VersionOne, and eXPlainPMT). Everyone comes from a different perspective, of course, and I have nothing against how other people choose to work. But one request keeps coming up that bugs me: the insistence that the tool support the ability to do task tracking.

The desire to manage tasks in an agile process is evidence that a team is not collaborating. They are instead using silo-mode development: 1 story -> 1 developer. In lieu of tracking progress by marking off completed stories, they look at progress in terms of what tasks have been completed. May as well go back to waterfall.

It’s all about delivering the story. If you work in a collaborative mode that promotes this, there’s no need for tracking at the task level. (I’m not even going to mention the ludicrous idea that tasks ever outlive an iteration.)

Comments:

couldn’t agree with you more. We use scrumworks and you assign a point person to a story/pbi.

Then you add or delete tasks as needed.

we went to a csm class with danube too. the trainer said “are you in the business of keeping people busy or producing product?” I think this is the point of your blog postings.

definitely agree.

Our VersionOne tool met both requirements for us. We could start with task tracking if absolutely necessary and turn off at any point in the future with the click of a single check box. We actually started with task tracking turned off and never looked back.

I don’t agree that task tracking is an evil. For example, we at TargetProcess use tasks as Definition of Done. We have tasks for each user story like Implementation, Create Acceptance Tests, Testing, Code Review, etc.

Definitely tool should make it possible to disable task tracking, but it brings value as well.

Note that I didn’t say “task tracking was evil.” It’s one way of working, and if it works for you, go for it. However, the better way is to structure things so task tracking becomes irrelevant. If you feel like you have to track tasks, your stories are probably taking too long to complete within the iteration.

Spread-out tasks are also a violation of lean principles.

I believe it is okay to make task tracking a requirement for tool selection since it is useful. I also understand where you are coming from that if the whole culture “requires” it, there might be a problem.

We use VersionOne because it handles both. We use task tracking heavily. As we work towards appropriately sized stories, we may need this less… but for now it helps us compensate for some other issues.

Stories and the Tedium of Iteration Planning Meetings

In “Tools, Iterations, and Stories,” I said you should “focus on implementing and completing stories, not iterations. If your iteration is 10 days, and you have 10 stories of 1 point each, you should have delivered one story by the end of the first day, and two stories by the end of the second day, and so on.”

Then, in a blog post titled “Stories and the Tedium of Daily Standups,” I talked about how a focus on completing stories, not tasks and iterations, would make daily stand-ups interesting enough to bother with (anew–since many teams that initiate daily stand-ups often find them boring and thus slowly stop doing them).

There’s another important side-effect of organizing an iteration around incrementally completing stories: Iteration planning meetings are more interesting.

Implicitly, to be able to complete stories as an iteration progresses requires team members to actually collaborate on a story. Imagine that. It’s at the heart of the emphasis on continual communication in agile, yet many teams tend to miss this key point. In my next blog posting I’ll talk about the side-effect of improved quality. For now, I’ll restrict my thoughts to the impact of story planning on iteration planning meetings.

If an iteration planning covers four stories to be implemented by a team of four developers, there are two primary ways this meeting could go: 1) The customer details each story by focusing on each individual that will work it, or 2) The customer details all stories, discussing them with all four team members. The downside of option #2 is that it will probably take a little longer to work through all the stories. In fact, if you went with option #1, you really wouldn’t need a team meeting. The customer could just meet individually with each developer.

Effectively, what you have with option #1 is a meeting in which 3 out of 4 developers have little interest in the story discussion at any given point in time. Information about other developers’ stories is mental clutter, and consciously or subconsciously, each developer will tune out to some extent for 75% of the meeting. They will view iteration planning meetings as mostly a waste of time.

In contrast, option #2 requires everyone to be attentive. We all have to understand every story, and we most certainly have to start figuring out how each one breaks up. We probably need to do a little bit of design. People attending these sorts of iteration planning meetings are engaged. They leave the meeting with the impression that it held considerable value for them.

Atom