Three top tips for using Given When Then.

Behaviour Driven Development is like Jazz. It is a constantly evolving approach to communication between all those involved in the specification and delivery of value in software development. Aslak, the creator of Cucumber, has cut a vinyl called “Kind of Green“. As the co-creator of the Given-When-Then format, this is an MP3 I knocked together in my bedroom. Its not quite my vinyl, more of a sample.

As a coach I spend most of my time with Product Owner Teams and Managers in large enterprises with established products, normally with millions of existing customers. The product team who create the stories, or the “Three Amigos” consists of the Product Owner (Product Owner, Chief Product Owner, Product Director), A developer, A testers,…. and A business analyst, architects (business, technical, and security), UX Researchers, UX Designers, System Designers (Lean Services representing the call centre), Data Analysts, and the occasional tastapod. I find the tester is normally best placed to facilitate the “Three Amigos” session.

Top Tip 1: Start with the value

Most product investments start with a “Tea Bag”, a partially formed idea. No one ever wants a tea bag. The conversation goes like this:

• Someone: “I want want a tea bag!”
• Product Owner: “Why?“
• Someone: “Because I want a cup of tea”
• Product Owner: “Why?”
• Someone: “Because I’m thirsty and cold and its a habit OK?”
• Product Owner: “What customer segment does this someone represent?”
• UX Researcher: “The are a commuter, represented by Warren the Worker”
• Product Owner: “So if we meet this need for the Warrens, we should increase activity in our stores.”
• Chief Product Owner: “Activity is a good and righteous metric to move given the current state of our metrics.”

The role of the Chief Product Owner is to ensure that the Product Owner is investing in the right metrics. They ensure alignment across the portfolio. They are an optional member of the product owner team.

• Product Owner: “We will deliver a cup of tea to satisfy the habit and thirst need of Warrens to drive up in-store activity”
• Lean UX Smarty Pants: “Isn’t that like a whole load of hypotheses?”
• Cynefin Smarty Pants: “And that is why we will engage in multiple safe to fail experiments, some of which are oblique.”
• Agile Coach: “That means small Stories and Epics, respond to feedback from real customers.”

The “Find the Value” activity can involve the whole team, however the risk associated with certain aspects is owned by certain roles:

1. The product owner owns the risk that the investment should be moving an appropriate metric.
2. The Chief Product Owner owns the risk that the right metric is being moved given the wider organisational metrics.
3. The UX Researcher / Data Analyst owns the risk that the right customer segment / persona is identified.
4. The UX Reseacher owns the risk that the customer need identified is done so in appropriate manner.

The output of the “Find the Value” Activity is a design brief.

The design brief consists of:

1. The metric to be improved.
2. The customer segment / persona.
3. The need to be satisfied.

At this point, the chief product owner and product director can check to ensure that the investment is aligned with all the other investments in the portfolio.

Please note that this is quite a long post and I still have not got to the bit where talk about user stories and given when then scenarios. You need to do the “Find the value” step first, otherwise as the Cat from Cheshire would say “If you don’t know where you want to go, any way is just as good.”

Top Tip 2: Work Backwards

Once we have a design brief, the entire team can engage in creating designs to satisfy the brief. The UX designer owns the risk that the design process is righteous and good, even if non designers are involved, especially in the original brainstorming.

The first step moving backwards is to start with the need and take one step backwards to consider the output of the system that will satisfy the need of the customer. (The value to the customer is in the output of the system, the need that it satisfies). When we have a design, we can test it on users to get early feedback.

Consider an app that is a music version of IMDB. An example design brief might be “Increase number of customers (metric) for super users (User Segment / Persona), by meeting their need to know where significant events occured for one of their favourite artists.“. The designs that satisfies that output might look like the following, one of which has been discarded as a result of user testing. The user testing has suggested we are best focus initially on the design on the right.

There are two considerations when working backwards from the design. The first is the data that needs to be displayed on the output which is covered by information smells (article video). The second is the behaviour of the application, which is normally expressed using the Given-When-Then format.

Note that identification of data is a complicated problem that is the domain of the business analyst and the architects. There is a right, knowable answer that can be verified by research using information smells.

The behaviour of the application needs an understanding of the value to be delivered, the needs of the customer segment, the technical constraints, and the possible failure states, or “quality” paths. As a result, all of the product owner team should be involved at various points.

When specifying the behaviour of the application, the team should start with the output, which means the first thing they should write is the “THEN“. For example:

• THEN the app displays a map
• AND the user location
• AND the location of any “Lady Gaga sites”
• AND the description of any “Lady Gaga sites”

The product team can then discuss the ways that the user would access the output. What event would cause it to be displayed. There may be several. The ones that are not an initial focus become TODOs that become part of subsequent Epics.

• WHEN the user is within one mile of an “Lady Gaga site”

1. TODO: When the user selects map from “Lady Gaga” page

The “Three Amigos” product team can then create the Conditions necessary, or GIVENs.

• GIVEN the user has selected “Lady Gaga”
• AND there are “Lady Gaga” sites within a mile
• AND the user has enabled notifications on their phone
• AND the user has enabled GPS

Out tester with a black hat is recording the quality paths as TODOs for other Epics:

1. TODO – Lady Gaga not selected
2. TODO – Notifications not enabled
3. TODO – GPS not enabled

The product owner decides the tester can handle 1 and 3 on their own but wants to be involved in 2 as the product owner would like to design an e:mail to tell users what sites they missed.

Which gives us the following first scenario:

• GIVEN the user has selected “Lady Gaga”
• AND there are “Lady Gaga” sites within a mile
• AND the user has enabled notifications on their phone
• AND the user has enabled GPS
• WHEN the user is within one mile of an “Lady Gaga site”
• THEN the app displays a map
• AND the users location
• AND the location of any “Lady Gaga sites”
• AND the description of any “Lady Gaga sites”

The product team then takes each of the GIVENs and turns them into a THEN as they continue to work backwards:

• THEN the user has selected “Lady Gaga”

The event that triggered that was:

• WHEN the user selects “Keep me informed of nearby Lady Gaga sites”

In the following conditions

• GIVEN the user is on the Lady Gaga page
• AND the user is logged on

Top Tip Three – GIVEN-WHEN-THEN first, stories second.

The product owner team can then slice the Epic into Stories.Starting with the GIVEN-WHEN-THEN, work out which bits of the Epic are the riskiest to complete.

• GIVEN the user has selected “Lady Gaga”
• AND there are “Lady Gaga” sites within a mile
• AND the user has enabled notifications on their phone
• AND the user has enabled GPS
• WHEN the user is within one mile of an “Lady Gaga site”
• THEN the app displays a map
• AND the users location
• AND the location of any “Lady Gaga sites”
• AND the description of any “Lady Gaga sites”

The developer and architect might suggest starting with the map as they have not used the map service before. Or they might suggest the “Lady Gaga sites” because that uses a service on the new untested architecture.

The tester might suggest the location trigger (WHEN) because they are not sure how to test it effectively.

The UX researcher might suggest the location trigger (WHEN) because they are unsure how users will respond and they want to test it with a screen mock up.

The security architect is worried about whether people will enter bogus artist sites to spam friends or enemies.

The team orders the stories with the riskiest first. They do the story that is most likely to fail so that they can get quick feedback.

Note that this different to the way that many people advocate. I am suggesting you create the GIVEN-WHEN-THEN scenarios for the design first and then create the stories whereas most other people advocate creation of the stories and then the GIVEN-WHEN-THEN scenarios.

Bonus Top Tip – Micro-Service Design

Starting with the output makes the design of micro-services easier as well. You start with the last thing to be displayed. To do that, you need look no further than your THENs and combined them with your domain model generated using information smells. The input to the last service becomes the output of the preceding service.

 

• THEN the app displays a map
• AND the users location
• AND the location of any “Lady Gaga sites”
• AND the description of any “Lady Gaga sites”

 

1. getMap (Location)
2. getArtistSiteDescription (ArtistSiteLocation)
3. getArtistSiteLocations (UserArtistList)
4. getUserArtistList (UserId)
5. getUserId(Username, Password)

Hopefully working backwards will rid the world of projects where the Login screen is the first thing developed.