I think that getting an idea of complexity, and thus ROI, involves discussing what the product owner wants, and I’ve no objection with creating notes for a story that capture that discussion. I think that teams create headaches when they take that next logical step (breaking the story down) too soon. It makes the backlog unmanageable.

I’ve also found that despite team’s protestations that they need lots of detail to produce relative estimates of complexity, they can actually do it with less detailed information than they think. I worked recently with a very experienced agile practitioner and coach, and he felt strongly we couldn’t size the backlog for a new project without lots more discussion. I asked if we could spend just half an hour trying an affinity estimating exercise, and at the end of 25 minutes we had the sizing done.

Thanks for our comments!

- Keith

Your approach of using a hierarchical structure to the backlog is one I’ve used as well. Realize what we’ve done, though: now got a backlog consisting of fewer stories (the parent stories), with “notes” in the form of child stories, which is exactly what I’m advocating.

The thing that tends to happen with this approach, though, is that the child stories begin to develop priorities separate from their peers, and you can end up right back where you started from.

Thanks for your comments!

- Keith

Waiting to get a real idea of your development complexity can lead to owner frustration as you have to (if you’re being honest) give him a ‘bigger or smaller than a breadbox” estimate.

Or have I missed something along the way?