There are many ways to decompose a large task into smaller portions. When agilist start doing this there are a few general ways to do such a thing. Let's start by distinguishing between a story split and a story slice.
Splitting != Slicing
If you've spent some time with an ax and a pile of wood then you understand that many logs have a naturally easier way to split along with the grain direction. It requires much less energy to split a log than it does to slice the log.
If you've spent some time baking cakes you know that people like to slice cake. You never hear of a person wanting a split of the cake. Many cakes have multiple layers, sometimes with different flavors in each layer.
What does this have to do with software development stories? Well many software systems have layers, and it turns out that it is easy to split the layers apart. For example: the UI layer is easy to separate from the Persistence layer. Many organizations separate their teams along these boundary layers... and in turn then split their stories along those same lines. And yes this decomposition requires less energy. Less energy in the beginning, but overall may require much more energy when working and tested software is desired. (Hint: don't do it this way.)
How you choose to decompose stories in your organization should NOT be based upon your teams' competencies. If this is done then you are executing and abiding by Conway's Law.
Why would we agile software developers choose to decompose stories in a fashion that requires more energy in the initial break out? Good question. A good answer is that doing so requires us to use all of the communication structure from top to bottom, ensuring that it functions together appropriately. And it plays well with the iterative and incremental nature of development. Software is quite different from hardware, or other types of building things. It is quite reasonable to model a software cake with ZERO layers, and then add a vanilla layer followed by a chocolate layer. Doing this requires 3 very different architectures -or- one general-purpose cake architecture.
Another reason for slicing (not splitting) software stories is that we try to include actual user value in each slice. There are good questions that may be asked about stories that have little or no user value. For example: capture the detail information about an order and save in the DB for later. This "read-only" data is very suspicious. I love to slice that story out of the others and put it in the DONE, pile.
Why DONE, you might ask? Because all read-only data is useless - let's just assume our system will do the right thing when and IF that data is ever displayed. We can deal with the data when we display the data.
Years ago when building a VoIP product I was happily surprised when Sprint planning, when a story came up that was a repetition of a previous story type one of the lead developers suggested that one of the other teams should do this story this sprint. He continued, my team did a similar story last sprint, and if a different team did this story it would give them a chance to review our code and the implementation in detail, and perhaps improve upon the design. Also, rotating these stories throughout all the teams would leave the whole group familiar with the implementation and this knowledge sharing is important to the company.
Splitting != Slicing
If you've spent some time with an ax and a pile of wood then you understand that many logs have a naturally easier way to split along with the grain direction. It requires much less energy to split a log than it does to slice the log.
If you've spent some time baking cakes you know that people like to slice cake. You never hear of a person wanting a split of the cake. Many cakes have multiple layers, sometimes with different flavors in each layer.What does this have to do with software development stories? Well many software systems have layers, and it turns out that it is easy to split the layers apart. For example: the UI layer is easy to separate from the Persistence layer. Many organizations separate their teams along these boundary layers... and in turn then split their stories along those same lines. And yes this decomposition requires less energy. Less energy in the beginning, but overall may require much more energy when working and tested software is desired. (Hint: don't do it this way.)
How you choose to decompose stories in your organization should NOT be based upon your teams' competencies. If this is done then you are executing and abiding by Conway's Law.
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.If you are doing this - you should stop, and rethink your designs.
— M. Conway
Why would we agile software developers choose to decompose stories in a fashion that requires more energy in the initial break out? Good question. A good answer is that doing so requires us to use all of the communication structure from top to bottom, ensuring that it functions together appropriately. And it plays well with the iterative and incremental nature of development. Software is quite different from hardware, or other types of building things. It is quite reasonable to model a software cake with ZERO layers, and then add a vanilla layer followed by a chocolate layer. Doing this requires 3 very different architectures -or- one general-purpose cake architecture.
Another reason for slicing (not splitting) software stories is that we try to include actual user value in each slice. There are good questions that may be asked about stories that have little or no user value. For example: capture the detail information about an order and save in the DB for later. This "read-only" data is very suspicious. I love to slice that story out of the others and put it in the DONE, pile.
Why DONE, you might ask? Because all read-only data is useless - let's just assume our system will do the right thing when and IF that data is ever displayed. We can deal with the data when we display the data.
Years ago when building a VoIP product I was happily surprised when Sprint planning, when a story came up that was a repetition of a previous story type one of the lead developers suggested that one of the other teams should do this story this sprint. He continued, my team did a similar story last sprint, and if a different team did this story it would give them a chance to review our code and the implementation in detail, and perhaps improve upon the design. Also, rotating these stories throughout all the teams would leave the whole group familiar with the implementation and this knowledge sharing is important to the company.
Comments