Agile User stories and Domain-Driven Design (DDD)

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.