Everyone loves a good Story
For development teams, especially Product Owners, some tips that might help you do great story-driven development.
Let me correct a few common misunderstandings before I even say anything else.
A “Story” in agile development..
..is not a name of a JIRA ticket
..is not something a Product Owner writes alone, passes under the door and the “doers do”
..is not just the title of the story. That would be like saying “Let me tell you a joke about sailors.” And then not telling the actual joke about sailors. Boring!
“Stories” are used in agile development to describe in simple language the user(s), their problem and a potential solution to it. A classical Story format, which many can identify, goes like this:
As user <user category, type, persona> I want to <do something in the software> so that <benefit, outcome>.
It’s not just that though, best stories are actually told, not written. You need to have that real conversation to build shared understanding.
The development team then has a little more flexibility on implementation, how the story — most importantly its expected outcome — can be reached in the software, within the boundaries of Acceptance Criteria (read on for more on that).
“Stories” get their name from how they were supposed to be used — primarily told, not written. You still need to record what you agreed though, and for that JIRA works fine, like index cards in a library. But it is very important that you have a real conversation about each story in the team, to build a shared understanding before you build software. Talk is cheap, weeks of development and Red Bull isn’t. This conversation is usually done in story workshop meetings or “backlog grooming”.
Teams sometimes use the mnemonic “CCC” for Card-Conversation-Confirmation
Card means that a team member, usually the Product Owner, introduces the card, story to the team. Why a “card”? Originally many teams used paper or cardboard index cards for stories, before the world was plagued by issue tracker software. Nowadays we sadly discount them as “tickets”. But I digress.
Conversation follows, with examples, questions, clarifications, hopefully lots of colorful drawings.
When preparing stories, talk together in examples how this feature would be used. Remember if you’re keeping outcomes in mind, you’ll need to talk about who does what in your software.
Don’t just describe what the software does; give specific examples of users and what they’d do in your product.
Talk about:
- Obvious examples
- Typical examples
- Complicated examples
- Terrible, awful, no good, very bad day examples
- Terrific, ideal, happy day examples
Confirmation, or Acceptance criteria, means agreeing and recording (in JIRA in our case):
What will we check to confirm this story is done?
How will we demonstrate this story at sprint review?
Have non-functional requirements been considered (security, privacy, performance..)
Extra credit for considering these when recording a story:
How will we measure success when we release this?
How do we instrument it to know it is working? (like event logging)
How do we document it?
Sources, images and inspiration:
Illustration by Jeff Patton, available at Dropbox — * Shared Course Material under CC-BY 4.0
