In this episode, we’re joined by Jeffrey Davidson.  Jeffrey will help us to better understand how to get better at user stories and how behavior driven development (BDD) helps create a shared understanding.  We also discuss how to create the nirvana state of living requirements.


Jeffrey Davidson is the past president of the IIBA Dallas chapter and is an agile coach and trainer.  Jeffrey is a frequent speaker at industry conferences where he discusses writing better user stories and other topics related to improving project and team performance.

After listening to this episode, you will understand:

  • The three Cs of user stories
  • How to use acceptance criteria to specify details in a user story
  • The benefits of using behavior driven development
  • How the Three Amigos technique can uncover missed requirements
  • How BDD will make auditors love you

Show Notes

What is a User Story?

A user story is a tool to help you to organize your work.  It’s a means to help you understand and make sure you’re getting the right stuff done.


The Three Cs

A user story has three components – a card, a conversation, and a confirmation (based on the work of Ron Jeffries).  The card is in reference to the small index card on which user stories were originally written.  User stories should be brief with just enough to know the intent.

Conversation means that it’s a reminder that we need to have a conversation or a reminder of a conversation we’ve already had.  The confirmation is the acceptance criteria and helps you to understand when you’re done with the story.

A user story is not the requirement.  It’s a statement about the intent, the functionality, and why it’s important.  If there are what can be referred to as requirements in a user story, they’re the acceptance criteria.


What is Acceptance Criteria?

Acceptance criteria are the conditions that must be true for the story to be done.  Acceptance criteria and the conversation we should be having about what functionality we’re delivering is best done through forms of a captured conversation.

“Acceptance criteria is really your proof of understanding.”


That’s where Behavior Driven Development (BDD) comes in

At its heart, BDD is about understanding.  BDD is somewhat like a modified version of a use case.  Is should be from a user role perspective based on the goal they’re trying to achieve.  BDD states the interaction and behaviors of the user and the system.  Start with a given context and articulate the expected response when they perform a specific action.

The format includes context, action, and response.

  • Given . . . (a particular role in a context)
  • When . . . (they perform a specific action)
  • Then . . . (the expected response of the system)

As a species, humans communicate best in two ways – stories and pictures.  The given, when, then structure creates a framework for a story that is understood by the entire team as well as end users.

The benefits of using behavior driven development are that the statements are in an easy to understand language and they do not specify the design.  Using BDD increases knowledge of the business domain and allows you to create better solutions for your users.  Additionally, by automating the testing you can achieve the nirvana state of living requirements.


Recommended Next Steps

If you’re new the industry, review some of the information about behavior driven development.

If you’re experienced, get together with two other people on your team (Three Amigos) and discuss how the system should interact with a specific role given a context.



Links mentioned in this episode


Thank you for listening to the program

To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes.

Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.