2024 Public Training Schedule
November 18 – 21, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- February 9, 2022
- Say What, Why, and for Whom Before How
I’m wrapping up this series of blog posts based upon Seven Strategies for Writing Better Stories from my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software, with my last strategy–use acceptance criteria.
There are many ways to define or break down and split up user stories. Generally speaking, the smaller the better because smaller stories are faster to implement, faster to verify, and give us the opportunity for more frequent feedback. We like small stories and as long as we can see stories are composed of smaller stories then we can decompose them and construct them so that we can recompose them into fuller features later.
A lot has been written on story breakdown. Mike Cohn’s book User Stories Applied is a classic and offers many techniques for story breakdown.
Generally speaking, I find that stories are big, and we don’t like big stories, because of only two fundamental reasons. A story is big either because it is a compound story or because it is a complex story.
If it’s a compound story, then break it down. You already recognize that it’s composed of multiple sub-stories so make each sub-story its own story. Compound stories are great because you can easily split them apart and then later put them back together.
How small should stories be? My answer is as small as possible while still deriving value to the user. Ideally, I’d like to be able to implement a story in less than four hours, and with a good continuous integration server and a clean codebase, you might be amazed at how much can be accomplished in four hours.
The other reason I find stories are big is that they are complex stories. Complex stories are stories that have components that are both known and unknown. It’s the unknown components that make a story complex. When I encounter a complex story then what I try to do is separate out what I know from what I need to know and then iterate on what I need to know until I shrink the unknown and expand the known.
For example, I might research a particular library or technology that I might want to use to accomplish a particular task. Whatever the unknown is, I’ll work on moving it into the realm of the known so that I can better manage it.
Whatever way I define stories, I want to be focused on making them provide value so I define stories in terms of the story’s acceptance criteria. In other words, a story should be defined by the value that it creates.
This is represented by the acceptance tests that we’ve defined for our stories because when our acceptance tests pass our stories are finished and ready to deliver. This makes it really clear where we stand when we’re developing on an Agile project and we can all breathe a sigh of relief.
Previous Post: « Think About Edge Cases
Next Post: Break Compound Stories Down into Components »