Author Tim Walker, CEO & Founder, The Agile Tester, LLC
I’ve been a huge fan of “Executable Requirements” for more than a decade. I have delivered many classes (“Executable Requirements with FIT and FitNesse”). I’ve followed the evolution of these powerful approaches to software engineering and have seen the state of the art as it’s sashayed its way along through the x-Behaves (jBehave/rBehave), Story Runner, RSpec and, most recently, Cucumber.
Earlier this year Matt Wynne, one of the contributors of Cucumber and co-author of “The Cucumber for Java Book”, gave a talk where he extolled the virtues of Behavior Driven Development as the force that could “save Agile”. I couldn’t agree more.
As a software engineer these are techniques I always reach for and consider essential. I have built test labs using Cucumber for Smart Grid devices. I have used Cucumber to help rewrite one of the largest systems in the Department of Treasury where thousands of business rules are verified and I have used Cucumber to describe and verify the behavior of “infrastructure as code” using the EC2 API and Docker.
Jeff Patton’s “User Story Mapping” is an excellent way to draw outuser stories using a narrative flow and which creates a two-dimensional backlog. This extra dimension allows us to drill down on different user stories, explore and group additional stories and creates an excellent opportunity for visually defining minimum viable product. It’s also extraordinarily powerful when used in conjunction with Behavior Driven Development, which is also known as “Specification by Example”.
In a modern Agile workflow, we delay the creation of details as long as practical. This keeps us from spending time specifying details of something we may never build, but also allows us to specify details when we know the most about them and keeping those details fresh in our minds when we drop down a gear to implement them using Behavior and Test Driven approaches.
Story Mapping can be used anytime to help visualize the user story narrative for a user of a system, or Persona. We are admonished to use real names of real people who are using the system to help us understand the way different users engage with it. We can then use Behavior Driven Development to drive out the details in a directly executable format and begin our “outside-in” development to help us deliver the feature while “baking quality in” and managing scope.
Let’s give an example.
Let’s assume that we are developing mobile software for teenagers to keep them safe while they are driving. The idea behind our software is to disable incoming and outcoming text messages while the vehicle is in motion.
The Story Mapping narrative might go like this:
Rhonda gets in her Honda
Rhonda Checks her Logs
Rhonda Sets up Autoreply
Now, using the Good, Better and Best approach to Story Mapping we might consider something for a later release
Rhonda sets up AutoReply with a Video Call
Rhonda sets up AutoReply for Different Speeds
Now, any one of these scenarios might make it into the backlog as a user story.
In order to safely notify friends when I am driving, I’d like my cell phone to automatically reply with a default message when my vehicle is moving, so that I can concentrate on driving while letting my caller know why I am not responding.
When it is time to flesh out the details of this user story we can use Specification by Example to do the job.
Feature: Basic Auto Text Reply when Vehicle is moving
In order to safely notify friends when I am driving
I’d like my cell phone to automatically reply with a default message when my vehicle is moving
So that I can concentrate on driving while letting my caller know why I am not responding
Background:
Given my cell phone is in motion and is travelling at least 15 MPH
Scenario: Use defaults to answer SMS Message
When a SMS message is received
Then a default SMS is sent to the sender
Scenario: Use defaults to answer a voice call
When a phone call is missed
Then a default SMS is sent to the caller
As you can see, just thinking about the problem made us handle the case where we might decide to implement the basic behavior when a regular voice call is received, even though that’s probably another story altogether. In any event, we know clearly what is in scope to be developed and a simple (and functional) application could be delivered. In this case, we’re not allowing any additional configuration, just specifying a couple of defaults (the speed of the car to auto generate a response and the fact that a default message will be provided).
Using this example to get to work on our story “outside-in” is very easy. We’ll simply execute Cucumber, use the snippets it generates for us, add these to our steps files and start implementing the code using TDD. In this fashion, we have a simple and testable design, by default, but when we start working on additional behavior we’ll know that our basic case stays working.
I invite you all to attend my upcoming workshop on Behavior Driven Deveopment for Agile Teams. It will be held on December 8-9, 2015 in Broomfield, Colorado at the ALoft Hotel.
I’ve been a huge fan of “Executable Requirements” for more than a decade. I have delivered many classes (“Executable Requirements with FIT and FitNesse”). I’ve followed the evolution of these powerful approaches to software engineering and have seen the state of the art as it’s sashayed its way along through the x-Behaves (jBehave/rBehave), Story Runner, RSpec and, most recently, Cucumber.
Earlier this year Matt Wynne, one of the contributors of Cucumber and co-author of “The Cucumber for Java Book”, gave a talk where he extolled the virtues of Behavior Driven Development as the force that could “save Agile”. I couldn’t agree more.
As a software engineer these are techniques I always reach for and consider essential. I have built test labs using Cucumber for Smart Grid devices. I have used Cucumber to help rewrite one of the largest systems in the Department of Treasury where thousands of business rules are verified and I have used Cucumber to describe and verify the behavior of “infrastructure as code” using the EC2 API and Docker.
Jeff Patton’s “User Story Mapping” is an excellent way to draw outuser stories using a narrative flow and which creates a two-dimensional backlog. This extra dimension allows us to drill down on different user stories, explore and group additional stories and creates an excellent opportunity for visually defining minimum viable product. It’s also extraordinarily powerful when used in conjunction with Behavior Driven Development, which is also known as “Specification by Example”.
In a modern Agile workflow, we delay the creation of details as long as practical. This keeps us from spending time specifying details of something we may never build, but also allows us to specify details when we know the most about them and keeping those details fresh in our minds when we drop down a gear to implement them using Behavior and Test Driven approaches.
Story Mapping can be used anytime to help visualize the user story narrative for a user of a system, or Persona. We are admonished to use real names of real people who are using the system to help us understand the way different users engage with it. We can then use Behavior Driven Development to drive out the details in a directly executable format and begin our “outside-in” development to help us deliver the feature while “baking quality in” and managing scope.
Let’s give an example.
Let’s assume that we are developing mobile software for teenagers to keep them safe while they are driving. The idea behind our software is to disable incoming and outcoming text messages while the vehicle is in motion.
The Story Mapping narrative might go like this:
Rhonda gets in her Honda
- Starts the car and drives off
- When a text message is received while the car is in motion
- Then a text message is returned to the calling number
- And a log is maintained
Rhonda Checks her Logs
- Rhonda gets home
- She checks her call log
- She replies to anyone
Rhonda Sets up Autoreply
- Go to app settings
- Open AutoText
- Open Configure AutoReply
- Set Minimum Speed to 15 MPH
- Set Message to be “Rhonda is driving her Honda and will Reply when it’s Safe!”
Now, using the Good, Better and Best approach to Story Mapping we might consider something for a later release
Rhonda sets up AutoReply with a Video Call
- Go to app settings
- Open AutoText
- Select Configure Video Reply
- Record a Video Message
- Save with a name
- Select that Video Message for AutoReply
- Set Minimum Speed to be 15 MPH
Rhonda sets up AutoReply for Different Speeds
- Go to App Settings
- Open AutoText
- Open “Slow” Auto Text
- Set Minimum Speed for Slow to be 15 MPH
- Set Message to be “Rhonda is fighting traffic and will call right back!”
- Open “Medium” Auto Text
- Set Minimum Speed for Medium to be 25 MPH
- Set Message to be “Rhonda is delivering mail in her Honda and will call when it’s safe!”
Now, any one of these scenarios might make it into the backlog as a user story.
In order to safely notify friends when I am driving, I’d like my cell phone to automatically reply with a default message when my vehicle is moving, so that I can concentrate on driving while letting my caller know why I am not responding.
When it is time to flesh out the details of this user story we can use Specification by Example to do the job.
Feature: Basic Auto Text Reply when Vehicle is moving
In order to safely notify friends when I am driving
I’d like my cell phone to automatically reply with a default message when my vehicle is moving
So that I can concentrate on driving while letting my caller know why I am not responding
Background:
Given my cell phone is in motion and is travelling at least 15 MPH
Scenario: Use defaults to answer SMS Message
When a SMS message is received
Then a default SMS is sent to the sender
Scenario: Use defaults to answer a voice call
When a phone call is missed
Then a default SMS is sent to the caller
As you can see, just thinking about the problem made us handle the case where we might decide to implement the basic behavior when a regular voice call is received, even though that’s probably another story altogether. In any event, we know clearly what is in scope to be developed and a simple (and functional) application could be delivered. In this case, we’re not allowing any additional configuration, just specifying a couple of defaults (the speed of the car to auto generate a response and the fact that a default message will be provided).
Using this example to get to work on our story “outside-in” is very easy. We’ll simply execute Cucumber, use the snippets it generates for us, add these to our steps files and start implementing the code using TDD. In this fashion, we have a simple and testable design, by default, but when we start working on additional behavior we’ll know that our basic case stays working.
I invite you all to attend my upcoming workshop on Behavior Driven Deveopment for Agile Teams. It will be held on December 8-9, 2015 in Broomfield, Colorado at the ALoft Hotel.
RSS Feed