Using Specification by Example in an online sales flow context

[Martijn van der Velden]

Hi,

After attending the Specification by Example course (given by Gojko, Amersfoort, 21st and 22nd of June, company NS), we would like to practice with this method in one of our projects. 

Nowadays, customers can buy international train tickets via a (online) sales flow. The process of a sales booking is search for train connections and related offers, create a provisional booking, add customer and traveler(s) details, enter the payment details and confirm the booking. The current sales flow only supports a single or return trip within one booking. We would like to extend this flow by allowing the customer to add several trips into one booking; these trips can consist of several different origin and destination stations, different groups of travelers, and different outbound and inbound travel dates. A functionality called 'shopping cart' should support these different use cases of collecting the offers for one booking. Finally, the customer can finalize and pay this booking in one transaction.

What we already prepared in this topic is a list and priority of use cases which the business would like to be supported by the shopping cart. Also, we already did extended analysis of the technical limits of the booking system in this context. In this case, there will be a lot of work for both front-end developers as well as back-end developers of the REST service integration layer.

By using specification by example we would like to create shared understanding of this topic within a group of business stakeholders and all team members of our scrum team (roles like product owner, developer, test). Afterwards, we would like to use specification by example to define and develop the test automation of the several use cases.

While preparing the shared understanding workshop we need some advice for our approach. We already should be able to address the right selected stakeholders as well as give an introduction of the topic shopping cart. The goal of the workshop is to create shared understanding and to detect undefined areas in this topic.

Could you give advice how to get to a deeper level by creating groups of stakeholders in this workshop and let them ask all kind of questions (like the Blackjack game during the course)? We are also looking how to get to new models (if there any?) as there is already much (technical) research information available in this topic.

Friendly regards,

Martijn van der Velden

[Gojko Adzic]

Hi Martijn,

The diverge/merge exercise we did during the workshop should be a good format for something like that if you can get everyone in the same room. The inputs into that are some initial examples and a good breakdown of scope, so you have chunks that could be discussed by groups in short cycles of time. 

In terms of creating groups of people involved in the exercise, I usually let people self-organise and shuffle groups between each session, so the composition on each individual group isn't such an issue, but if you do need to give people some stricter guideline then try mixing up the roles so groups are not homogenous (so eg no group has only developers, or only analysts). the ideal size for each sub-group in a diverge cycle is 4-5 people. as you've already done analysis, I suggest that people who've participated in detailed analysis stay in the middle of the room and facilitate (perhaps also provide an introduction with the first few initial examples), but do not actively write examples during the diverge part so that others can visualise their understanding.

depending on how many stakeholders you want to engage, and at what level, you may want to get the stakeholders to work in the groups as well, or if there's one or two key decision makers, perhaps keep them in the middle of the room to help you answer questions and facilitate.

the new models usually emerge either from differences in structure between the ways how groups write examples, or from the discussions on examples when trying to nail down the decisions asked by the initial questions. Look at areas that turn out to have a lot of complexity or lots of examples. Try finding implied rules or concepts, or groups of data that are related closer to each-other than the rest. asking people to summarise something and then carefully listening to detect words or concepts that are in the summary but not the examples might point to implied rules. another good hint is to identify areas where the same or similar thing is called by different names in several groups, or where different things get the same name.

gojko

gojko

--
You received this message because you are subscribed to the Google Groups "Specification by Example" group.
To unsubscribe from this group and stop receiving emails from it, send an email to specificationbyex...@googlegroups.com.
To post to this group, send email to specificati...@googlegroups.com.
Visit this group at https://groups.google.com/group/specificationbyexample.
For more options, visit https://groups.google.com/d/optout.