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.