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

Start by writing the story from a user perspective. Use the user story template:



“As a …”

“I want …”

“So that …” Write the acceptance criteria. Write specific, testable acceptance criteria. Make sure they’re SMART. 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. 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 refinement session.

Many teams start writing acceptance criteria in the Gherkin language (“Given .. When … Then.. ”) too early in the process. That results in a long refinement session. When the story is finally refined, it’s almost done, too. Write the scenario’s during the sprint.

Implementing the story

It takes time to get the scenarios right. Write scenarios during the sprint. Bad specs = bad code. It makes sense to focus on getting specifications right, first. The development process looks like this:

The process of implementing a user story

The example mapping session in the refinement session yielded examples that go with each acceptance criteria. Start by converting those into Gherkin scenarios using the “Given … When … Then …” template. The examples probably don’t cover all edge-cases. Make sure the examples do. These scenarios represent the acceptance criteria of the user story. Usually, these are the scenarios to validate before showing the final product to the product owner and the stakeholders. Validate the scenario’s with the stakeholders as soon as possible.

* Make sure the scenarios are correct.

* Make sure the stakeholders understand the scenarios.

* Make sure the team and the stakeholders have a common understanding of the language used in the scenarios. Use a cucumber framework like SpecFlow to validate the scenarios automatically. Implementing the test-code first. The test will fail and that’s fine. Start implementing the new functionality until all tests, including the ones from previous user stories, pass. Show the final solution to a stakeholder or somebody that can represent the stakeholder. Demonstrate the final product to make sure the final product conforms to what was agreed upon. Write new scenarios, and thus new tests, if it turns out the current scenarios are not complete.

A product that is compliant with the acceptance criteria of all (previous) stories is shippable. So ship it!

Common pitfalls

Don’t use scenarios to describe the user interface:

“Given a user navigates to http://localhost/somepage.aspx?x=23523&q=foobar”

“And the user selects option ‘0’ in dropdownlist ‘#ddl-foo-pnl2-pane2–235232’”

“When the user clicks the button with id ‘#btn-foo-form24523-n’”

“The panel ‘#pnl-foo-primary-f35232-red’ exists”

Use meaningful scenarios to describe behavior instead:

“Given the user wants to receive the newsletter”

“When the user submits the form”

“Then the user sees a message that says: ‘We’ll send the newsletter!‘ ’”

“Given a user navigates to http://localhost/somepage.aspx?x=23523&q=foobar” “And the user selects option ‘0’ in dropdownlist ‘#ddl-foo-pnl2-pane2–235232’” “When the user clicks the button with id ‘#btn-foo-form24523-n’” “The panel ‘#pnl-foo-primary-f35232-red’ exists” Use meaningful scenarios to describe behavior instead: “Given the user wants to receive the newsletter” “When the user submits the form” “Then the user sees a message that says: ‘We’ll send the newsletter!‘ ’” Don’t write specifications alone. Writing specifications is like writing a contract. Writing it down unambiguously proves to be challenging. Writing them with a peer vastly improves the quality of the specifications.

Releasing the software

Tools like Gitlab and Azure DevOps provide automated release pipelines. These pipelines support fully automated installations of the software in different environments. They support test automation, too. The release process looks like this:

The developer commits his code changes to the repository.

The developer’s commit triggered a build process. It builds the new version of the code and runs all automated tests. If this step fails, the release process stops.

The test-run triggers an off-the-shelve plug-in (Pickles). This tool generates functional release documentation, automatically.

The new version of the software is installed in the test-environment, automatically. The team can validate that the new software integrates with other systems it depends on.

The new version of the software is installed in the user-acceptance-test automatically. The stakeholders can see the new functionalities before they go live.

If the stakeholders are happy with the new version of the software, the team approves the installation in the production site.

Summary

Doing Behavior Driven Development in a Scrum team, efficiently, requires some changes to the refinement session. Creating testable acceptance criteria for every user story, with relevant examples. Convert them to Gherkin scenarios during the sprint, and automate them so they can run in the deployment pipeline.