On Monday night at our DDD Denver meetup we ended up having a valuable and lively group discussion using a modified "Lean Coffee" format. The four questions we covered (in order) were:
Where to start in developing a domain model?
What is the biggest hurdle for a team adopting DDD?
What is the intersection of DDD & agile user stories?
Techniques for implementing DDD across geographically dispersed teams
As we discussed the intersection of DDD and user stories, I mentioned a quick reference guide that I have used for my own coaching and training over the years. There seemed to be a lot of interest in having me share the resource more widely.
So I am now making my "Stories for Design and Delivery" reference freely and publicly available.
This double-sided quick-reference provides a wealth of distilled content about how to integrate stories and design, including making decisions about splitting based on business subdomain.
Click on either thumbnail below to download the full-size PDF version.
I put the first version of the guide together back in 2009 as a quick reference guide for Mike Cohn’s User Stories Applied. I needed an easier way to get the whole team to understand user stories without forcing them all to read the book (as good as it is, this wasn’t going to happen). I printed and laminated a bunch of copies and distributed them to the team.
Iteration two was several years ago when Richard Lawrence published his excellent Patterns for Splitting User Stories post (also referenced as a footnote on the guide’s second page). At that time I incorporated Richard’s material into the second page, greatly improving the guidance around splitting stories.
I’ve used this guide many times over the years in my classes and coaching, teaching teams how to collaboratively and creatively decompose their functionality into manageable increments.
Iteration three was almost a year ago, when I decided to move away from the conventional agile community’s terminology and emphasis on process, and focus on how stories can support design, rather than fragment it. I tried to approach it first and foremost as a DDD practitioner, concerned about putting design first. So I incorporated my current understanding of how domain modeling, tactical design practices and strategic design (i.e. mainly subdomain distillation) fits with how most teams manage their work items.
Note: I’ve deliberately defied convention by not calling them _user stories. Stories - as I conceive of them - may relate directly to customers, users, stakeholders and even predominantly technical considerations, not just end users. Some heavily design-focused stories, such as building an anti-corruption layer in front of a back-end system, might only be exposed to users tangentially via seemingly unrelated functionality (from their perspective)._
Just recently, Richard has reworked his story splitting guide into an excellent flow chart: How to Split a User Story, which I highly recommend as a more process-focused complement to mine.
I hope this is as helpful to others as it has been to me. Let me know in the comments if you do find this useful. And please let me know any ways I might improve the quick reference guide.
The document is designed to be printed double-sided. I recommend laminating your copies before you hand them out so they last longer and are less likely to get lost in a pile of paper.
About the Author
If you are looking for an expert hands-on team coach and design mentor in Domain-Driven Design (DDD), BDD with Cucumber, or lean/agile process Paul is available for consulting and training through his company, Virtual Genius LLC.