Tasks are teh suck

Here’s a little something I wrote to the Scrum list, to the 14,321st team who are having trouble using tasks in Scrum planning. This team was having trouble getting through the planning in under 2.5 days. (!)

Well, first of all, tasks are teh suck. Breaking the job up into tasks means you have to put it back together, which is always difficult. I’m writing a Kate chapter about that right now.

What I recommend as a planning process is this:

  1. Product owner writes story on whiteboard, and explains it.
  2. Briefly discuss how the story will be tested.
  3. Developers briefly brainstorm and list technical steps needed.
    (Similar to tasks but we’re not going to do the work, nor track it that way.)
  4. Repeat until enough stories are on the board.
  5. Look at the list, draw the line where you’re confident you can accomplish everything above the line.
  6. Commit
  7. Do stories as a unit, not broken into tasks.
  8. Burn stories, not tasks.

Q: But for this to work, everyone would have to be able to work on everything.
A: Yes, that would be ideal. And you could do pair programming — that would fill in needed skills and people would learn as well.

Q: But even so, for this to work, stories would have to be very small.
A: Yes.

Recent Articles

Emergent Design

Martin Alaimo asked about the Manifesto Principle "The best architectures, requirements, and designs emerge from self-organizing teams."

XProgNew – Pivot?

Experience with Sinatra, and some thinking, cause us to look at a shift in approach. Martin Fowler was probably right.

Codea Calculator II

Ignatz and Jmv38 on the Codea forums commented on the previous article. I had hoped to do more anyway so here's the next one.