Behaviour Driven Development Tasks and Activities

Make small cards for each of these descriptions. Give a copy of these cards to small groups. Ask them to use the cards to design a BDD process.

The purpose of the exercise is to get people to understand the main elements of Behaviour Driven Development and that you can tailor the exact process to your circumstances. There are many ‘right’ answers.

Having said that, BDD doesn’t usually involve creating detailed requirements documents. Not all the tasks and activities are wise to include!

This material was inspired by Seb Rose’s article

Instructions

If you were doing Behaviour Driven Development, which of these tasks and activities would you include in your software development process? Make a BDD process diagram by laying the cards out on a table or sticking them to a whiteboard. The placement of the cards should show how your development process would look. Draw arrows between cards to indicate which order to do the activities in and when to iterate or act on feedback.

Note: you do not need to include all the tasks and activities in your BDD process diagram.

Retrospective

What: Review how the software development process went in the last sprint.
Who: Whole team including Product Owner.
Outcome: Process improvements or experiments to try in future.

Examples Workshop

What: Discuss one or more User Story, identify rules and example scenarios.
Who: at least 3 people, representing the Product Owner, Developer and Tester. Could be the whole team.
Outcome: several rules and examples to illustrate each User Story.

Create a User Story

What: Write a description of a new capability the software should have.
Who: The Product Owner or a Business Analyst.
Outcome: A sentence or two describing the user story.

Performance Testing

What: Operate the software under simulated load to examine whether it works as expected.
Who: Testers (often performance testing specialists).
Outcome: Information about whether the software works as expected or not. This information might lead to new or updated User Stories.

Review Scenario Formulation

What: Find out whether the formulated scenarios are correct and can be understood by relevant stakeholders.
Who: Business Analyst or Product Owner.
Outcome: Confidence the development team are building what the business needs.

Sprint Planning

What: Decide which User Stories to work on this sprint.
Who: Whole team including Product Owner.
Outcome: A prioritized list of stories and effort estimates.

Implement a User Story

What: Write code so that the software gains the capability described in the User Story.
Who: Developers.
Outcome: Working software. Scenarios can be successfully executed against the software.

Automate Scenarios

What: Write test code so that scenarios can be executed.
Who: Developers or Automation Testers or a Developer and Tester pair.
Outcome: Executable scenarios that can be run against the software. If the software doesn’t yet support the scenario in question, it fails with an appropriate warning.

Exploratory Testing

What: Exercise the software and look for missing features, scenarios, rules, or unexpected behaviours.
Who: Testers.
Outcome: Information about whether the software works as expected or not. This information might lead to new or updated User Stories.

Review Automated (Running) Scenarios

What: Find out whether the running scenarios are correct and can be understood by relevant stakeholders.
Who: Business Analyst or Product Owner.
Outcome: Confidence the development team have built what the business needs and that the running scenarios can be used as documentation.

Change Approval Board meeting

What: A decision is taken whether to release the latest version of the software to customers.
Who: Product Owner, Architects and others from outside the Development team.
Outcome: go/no go decision regarding the release.

Architecture Diagram

What: UML diagram describing the details of the architecture of the software.
Who: Architects from outside the development team.
Outcome: Developers have detailed instructions about how to implement User Stories.

Detailed Requirements Specification

What: Several pages of text and diagrams describing what to build.
Who: Business Analyst or Product Owner.
Outcome: Detailed instructions about what to implement including all the scenarios.

Formulate Scenarios

What: Examples formulated as Scenarios, using a Domain Specific Language.
Who: Developer or Developer and Tester pair.
Outcome: Scenarios added to the team’s shared repository.

Release Software

What: Create a Potentially Shippable product increment.
Who: Developer or a specialist release engineer.
Outcome: A deployable software package ready to release to users.