When tracking the state of an iteration/sprint I generally favor tracking stories (not tasks).

The good of the story

  • accountability (someone takes responsibility for it’s delivery)
  • favors generalism over specialization
  • can see the sprint at a glance
  • less to track

I only mention this because I once saw a team get so bogged down in tracking tasks, that they abandoned the visible workspace (because it there too many tasks to track) and a lot of it was just noise (i.e. a task for development, a task for QA, a task for code review etc).

Once we removed the tasks, and focused more on the story, the clouds parted a lot of stuff cleared up.

I know a lot of advice out there recommends tracking, estimating, and investing time in tasks (and I am not against doing that to help understand what needs to be done).

But generally I prefer to start with the story. See if you can deliver without the overhead of the task, and add it only if you can’t.

Advertisement