User Story Dogma

To articulate the definition of done with regards to acceptance criteria and a particular user story, many people are good and getting better. To articulate the definition of done with regards to an effectively written user story, we still have miles to go. The need for low/no-ceremony requirement definition is sound; however, low/no-ceremony does not imply pre-emptive thought to design is unnecessary.

Mike Cohn's intent in user story definition was to simplify what is historically an over-engineered, mis-understood, error-ridden process of filling out templates, defining gibberish contextual to the template and delivering nothing useful as a result. Delivering working code that matches a populated template full of refuse (an obvious synonym) is not success, nor should one be proud; hence, user story statements -- simple, quick, explicit, tacit.

Ample time to think through a user story's system implications, needs, risks and rewards sometimes appears to be lost in "be quick" which is itself a preposterous lunacy and easily a mistaken behavior masking laziness. User stories, use cases, shall statements or otherwise have all historically presumed someone would do the needful thinking up front where possible. Think of everything? Of course not. Think of most? That's why engineers get paid -- systematic, structured, pre-emptive thought.

For example:

User Story Statement
"As a user {type} I would like to perform {this action} so that I can accomplish {this goal}."

User Story Description
"(Describe the business problem) Lorem ipsum dolor sit amet, consectetur adipiscing elit. Duis quis sapien id tellus laoreet blandit. Fusce pede eros, malesuada nec, egestas ut, euismod commodo, justo. Etiam nibh elit, pellentesque ac, faucibus sed, dignissim porta, nulla. Ut vehicula interdum nibh. Aenean eu arcu in augue viverra faucibus. Suspendisse quis mi. "

Acceptance Criteria Testable Statements
1. Positive functional statement(s) testable definition of done (Must)
2. Negative functional statement(s) testable definition of done (Must not)

3. Load+Performance goal
e.g. {user/transaction mix, concurrency expectation, good == ?}

4. Data architecture goal
e.g. {sql/syntax req, sql perf def, sys call/stack penetration def, good == ?}

5. System infrastructure goal
e.g. {b/u/recovery def, hw/network needs, disk, i/o, mem, good == ?}

6. Fault/Failure goal
e.g. {logging standard, recovery standard, good == ?}

7. UI/User experience goal
e.g. {CSS stndrd, transact end2end elapsed time/keystrks/scr, good == ?}

And this just covers a problem statement, description and criterion for "done" and "good". Hereafter would we relative size, prioritize and then very importantly... task out each acceptance criteria using ideal effort hours and a rule of thumb where one task cannot require greater than three business days of effort for completion else it requires further decomposition.

I've heard it argued that the more extensive thought on acceptance criteria articulated above is best left to task-ing experiences. This logic may be sound IFF people actually take the time to task things out, but I neither subscribe to it, nor do I believe it effective. Absent the task out, and then absent the acceptance criteria build-out, we have subjective evolution of an interpreted user story statement between a product manager and a pair, if pair, believing that their hard work matters. As always, working hard does not mean working usefully.

The need for writing an effective requirement has not changed through the years, nor has the idiocy that comes with arguing requirement elicitation dogma. Light-weight no-documentation solutioning is neither XP, nor Agile; it is a betrayal of intellect for those who actually have some.

Use user stories; but think ahead farther than just functional declaratives.

No comments:

Post a Comment