One day, I was working with a team lead to build out their Continuous Integration (CI) system. He asked me to write down the requirements, so I did even better and wrote these user stories. Why was this "even better?" I find whenever I use the User Story Format, it makes me think differently about what I'm trying to do. (Especially the VALUE part "So that:." Then the Acceptance Criteria force me to put to paper the ideas of what is acceptable that I'm carrying around in my head but perhaps not communicating.
Every time I bother to use User Stories, I get higher quality documentation. Every time! The team lead I did this for agrees. The head of the PMO came by and said, "those user stories you wrote about CI are really clear" -- hey, this is a non-technical manager who understand the value of a technical implementation like CI because of User Stories!
As a: Team Lead
I want a: Continuous Build environment that compiles my code.
So that: the team can clearly see when we've checked in broken code
Acceptance Criteria:
Every time I bother to use User Stories, I get higher quality documentation. Every time! The team lead I did this for agrees. The head of the PMO came by and said, "those user stories you wrote about CI are really clear" -- hey, this is a non-technical manager who understand the value of a technical implementation like CI because of User Stories!
If you've more questions, Agile Thoughts podcast (episodes 1 through 8) did a series of short, fun, and creative episodes on the test automation pyramid. It won't put you to sleep, I promise!
As a: Team Lead
I want a: Continuous Build environment that compiles my code.
So that: the team can clearly see when we've checked in broken code
Acceptance Criteria:
- The moment code is checked in, the CI environment builds it and displays on the dashboard that the code is building.
- Check in uncompilable code and watch that the dashboard displays there is a problem.
