This is a quick guide to decompose a user story. There are lots of resources that explain methods to decompose a user story. In this case, there is a parallel with Perficient Denver office lunch time learning session. This is not rocket science, but rather, a quick guide to facilitate a forum. Therefore, use this article as an outline for a groom session. And, practice!
A team talks about a new activity. The most important thing is that the team has discussions with the attempt to achieve a common understanding. The team being a team has the highest value (also see Phases of a Backlog Groom).
Some Guiding Principles
MosCoW. The MoSCoW Method is a technique used to reach common understanding of business priorities. In story decomposition, the best value, the best next step is generally the “Musts.” This is a guide and not a a hard rule. Talk to each other and work through the decompose conversations with this in mind. But, keep in mind that decisions are dated, so they are likely to change in time. Must is when there is no point without this. Should is not vital, but is painful to leave out. Could is desirable if easy to get during Musts & Shoulds. Won’t is not happening at this time or unpalatable to one or more stakeholders.
MVP. The Minimum Viable Product is a product with just enough features to satisfy early customers and to provide feedback for future work. In story decomposition, the best value, the best next step is generally toward the MVP. Besides that, this is a guide and not a a hard rule. Side note, I never like the phrase MVP. I prefer “Most Valuable Product” and read a blog that expounds on this a bit (MVP may not be Maximum Value).
Vertical vs Horizontal cut. Finally, keep in mind that a vertical break down is better. We want to achieve an iterative addition to the baseline, but leave the baseline operational. There is a temptation to break down a story by role. Dev can do this piece and Test can do that piece. But, this is definitely not what we want to do here. An untested Dev piece is not a continuously deliverable addition.
5 Methods to Decompose a User Story
By Compatibility. In context of current environment. Consider platforms and browsers that are to be supported. Consider coding standards and the extent of re-use. Look closely at the current system and decide where this new code will live.
By Use Cases. Of course, look closely at what the end user needs to do. For example, consider happy and unhappy use cases. What is most important? What is absolutely needed now? Maybe, the first pass does not need to have all the bells and whistles.
By Business Rules. Business always has embedded rules. Many of these rules can wait until another pass. Proof of concept with a nominal flow may be the best first objective. For example, consider I/O and data type limitations and consider legal obligations.
By Interoperability. Other business flows will interaction with this new piece. Consider integration with adjacent systems, because, Are they all needed now? Consider upstream and downstream flow. Where will data live and what analytics and business intelligence is most valuable.
By Support Function. Finally, consider peripheral roles. Consider documentation, level of test and UX. Is this a final polished piece or a decent step toward something greater? For example, consider DevOps and the delivery train, support, and user assistance.
