How to combine Behavior Driven Development and Scrum

Going to production more often means less time to make sure new features don’t cause any trouble. Validating everything manually in a short amount of time seems impossible and prone to errors. Moving from waterfall to Scrum requires another approach: Functional tests that validate the software does what it’s supposed to do, automatically. That requires the process to change, too:

The refinement

Unclear specifications can cause bugs. Writing the specifications during a refinement session is inefficient and time-consuming. The following process describes how to get an efficient refinement process that yields clear enough acceptance criteria:

What the definement process looks like

1. Start by writing the story from a user perspective. Use the user story template:
   
   “As a …”
   “I want …”
   “So that …”
2. Write the acceptance criteria. Write specific, testable acceptance criteria. Make sure they’re SMART.
3. Make sure everybody understands the acceptance criteria. Plan a 20-minute example mapping session for every user story. Come up with examples for all the acceptance criteria of the user story and discuss them with the product owner. Save the example map, maybe add some notes, and translate those into specifications during the sprint.
4. When the team has a shared understanding of the story it is easy to estimate the effort it takes to build it.

Refined, estimated stories can be planned and built.

Common pitfalls

• Nobody builds things for the product owner. Eventually, an end-user or a stakeholder benefits from the new features in the software. Building it, showing it to the stakeholders and finding out it was built wrong, results in a lot of waste. Invite the stakeholders to the refinement meetings to prevent that.
• Writing user stories and the acceptance criteria, from scratch, takes lots of time. Usually, many acceptance criteria are pretty obvious. Writing those down in advance. Do that with a small delegation of the team: The product-owner, a tester, and a developer. This session is also known as a “The three amigos” session. It saves a lot of time and allows the team to focus on the criteria that deserve more attention during the…