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
- October 23, 2019
- Write the Test First
Another huge benefit of acceptance test-driven development or ATDD is that it helps us get clear on defining features for a specific type of user. And it also helps us get clear on why they want that future.
Why is really the key question. Why do we want to implement or build a feature in the first place? That really is the question and when we answer it we can often discover better ways of fulfilling what they want than how they originally thought.
What we define as a feature is one way for a user to get what they want. Understanding why a user wants what they want helps us find better ways of getting the user what they want. This is why a central part of the user story is why a user wants the feature in the first place. Just having this conversation often leads us to build better features.
Why often sets the context for a feature but there is something else that sets the context for why a feature is wanted, which is the who. No, I don’t mean the rock band although I think they’re awesome. I mean who the feature is for.
“Put yourself in their shoes” as the saying goes. When thinking about a user story and creating acceptance tests around user stories we want to always think about who it’s for and build stories for a particular user type. A user type could be any kind of user that has a specific set of requirements or needs from the system.
Understanding the different kinds of users of a system and why they need what they need from it helps us build a complete feature set for them. Many enterprise systems have multiple different user types that have different needs of the system and so understanding the feature trains for each user type, which is something that Jeff Patton talks about with story mapping, can be really valuable in creating full feature-sets that allow a particular type of user to do everything that they need.
We don’t build stories in isolation and we don’t write acceptance tests in isolation. True, we want our acceptance tests to be insulated from each other and not dependent upon each other for their execution but we want each acceptance criteria to build on itself so that we can express the full range of a feature.
Every feature in the system as a reason for being. It has users who are the ones who derive value and it has a definition or acceptance criteria. When we use user stories in conjunction with acceptance tests we are essentially automating the requirements process and by doing so we are saving enormous amounts of ambiguity while gaining tremendous clarity in what we are building. I’m a huge advocate for acceptance test-driven development, especially for helping teams work with their Product Owners more effectively and efficiently.
Note: This blog post is based on a section in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software called Seven Strategies for Seven Strategies for Measuring Software Development.
Previous Post: « Get Clear on the Benefits of What You are Building
Next Post: Automate Acceptance Criteria »