Say you are a Scrummaster walking along, minding your own business, and you come across a pile of user stories lying on the pavement. You pick the first one up, then the second one, then the whole pile of them and get yourself a stick of glue and begin to paste the stories together, hoping to get a view of the whole that ties all these stories together.
Or, imagine for a minute that these user stories are instead pieces of a jigsaw puzzle and it’s your job to make them into a big picture. The problem is that somebody has lost the box – you don’t know what the finished picture is supposed to look like. Suppose you use up all the pieces, but there’s something wrong. The person who lost the box, also lost some of the pieces.
What I’m talking about really is stories at different levels of decomposition; the hierarchy of stories, the project, release, iteration, of stories. If we haven’t got the project stories, we can’t make much sense of the lower level stories because we are unsure how the parts are supposed to hang together. If we have the project stories, that’s a different thing because we can break them down into lower levels that can actually be built in an iteration.
So we are agreed then that project stories break down into lower level stories, and it’s pretty straightforward to do that, but it’s still really important to make a picture of how those stories are related (their hierarchy of decomposition), because if we don’t know that, it’s just like having a smashed up humpty-dumpty at the bottom of the wall, and putting him back together again is just not going to happen.
If you enjoyed this post, make sure you subscribe to my RSS feed!
In the worse case we programmers are like the engine room on a ship the captain sees the iceberg and sends a signal down “Full Astern”. We do “Full Astern” and feel like we have completed our little task. But we have no awareness of the bigger picture. It would be better if we were aware of the fact that we were going through an area with many icebergs.