The Code, the Acceptance Criteria, and Does Anything Else Really Matter?

Somewhere along the line, I think software creators got a reputation for being insanely smart. This is valid, largely accurate, and totally okay.

Also somewhere along that journey, some organizations decided that since software creators are so smart, software creators didn’t need specific instructions. General goals for a user story would suffice.

Also also somewhere along the way, some other organizations realized that smart people get their own ideas. Often, those ideas often weren’t what management or the client wanted, so those organizations use all the character limits and fields included in the card program to define user stories. Down to the method names to be created.

Two extremes, staring desperately at each other across a gulch. A gulch full of software creators from both sides who have hurled themselves into the abyss after realizing they can never actually deliver what’s required because of terrible systems.

Definition of Done

I think part of the problem is the vocabulary, and how there’s somehow multiple sorta conflicting definitions of what a “requirement” is, and “acceptance criteria” similarly can mean different things to different groups at different parts of the cycle. What every piece of work actually needs is a definition of what “done” looks like — how do you know this goal is finished?

When I set out to hike a trail, I know when I’m done. Even on a interconnected set of trails in a national or state park, I know that when I get to the overlook, or loop back to the start, or reach the fork right before the bridge, that’s the end of the hike. It should be the same way with picking up a card — “Go for a hike” as a title with nothing else to go on is a terrible definition of done, and so is

• Wear the Walmart boots, not the Bean boots
• Drive your spouse’s car
• Head East out of your neighborhood
• Drive I-71 North to exit 183
• Find the Notch Valley Trail Head parking lot
• Park in the shade
  • etc etc…

Software creators are smart individuals who have been trained in the art of solving problems. If you give them a solution to implement, at best they will be bored and THAT is never a good thing. If you give them a poorly defined problem they’re going to fill in the blanks, which can lead to an implementation that isn’t actually useful in the wider roadmap.

Define the Problem in Sufficient Detail

The goal of a card should be to define the problem being solved. Be it a value story, a list of behaviors the software should have, a self explanatory wireframe showing what it should look like at the end, or ideally a combination of all that. If there are technical concerns — say, a specific database that needs to be involved or a security concerns to be considered — that should also live somewhere in the card.

You don’t want to be prescriptive on a solution before anyone’s started to pull back the curtain and started work on the card — what makes sense during a discussion with a product owner, backlog refinement or sprint planning might not make sense in practice. If the card is so specific one has to prove it wrong before they can do the work, that’s all bad.

But leaving it completely open ended is also a recipe for a terrible demo. Most software creators won’t have been in the meeting where the requirements were discussed with the client or product owner… meaning their solution to a minimalist prompt and it’s behavior might be absolutely inappropriate in the wider context.

TL/DR:

The goal in writing a card should be to put everything in it necessary for any member of the team to read it, maybe ask a couple clarifying questions, and come up with an implementation plan. The goal shouldn’t be to hand them an implementation plan. It should not be to create a cryptic post-it note reminder with a single sentence fragment. The card should resemble (in written form, obvi) that scene in “Apollo 13” after everything goes sideways: Gene Krantz first defining, and then telling the team to work the problem.