In this post I present an idea we had in a meeting recently. I am not sure it’s a good idea and would definitely like to know what you think about it.
The Setup
One way to look at teams implementing stories is this: Stories are pulled from a queue, then implemented and finally handed over to ‘business’, to decide whether or not a story is put into production.
In many typical setups there’s another process which is used to break down stories into small enough tasks which can actually be implemented. At some point there’s also a decision to be made about the order in which to implement the stories, but that’s not a topic of this post.
Often the breakdown is done in a whole-team meeting, which can be as long as half a day. The goal of this meeting is to find tasks for a number of stories.
The Idea
Avoid the ‘whole-team story-break-down meeting’ and instead have ‘meta stories’ which are put into the queue. Each meta story is about cutting only one story into tasks.
- Not all the team members have to work on this (although all can).
- Meta stories are put into the queue whenever there’s a risk that the team might run out of unimplemented stories.
- This is the main reason to give a high enough priority to meta stories: It’s in the very interest of a product owner (or however the role may be called) to provide enough work to the team.
- As soon as the meta story is broken into tasks, it can be prioritised and put into the corresponding position in the story queue.
Questions & Leaving Thoughts
I personally think it’s worth trying, probably in the form of a time-boxed experiment. There should be a way to decide whether or not, much like J. B. Rainsberger describes it in this presentation on vimeo. The description of running this kind of experiment starts around minute 30, but really, watch the whole video.
Can this work? Will it work? Has anybody tried this before? If yes: In what context? What were lessons learned?
