Are Use Cases Compatible with Specification by Example?

[Bob Rundle]

I have been working with SbE for the first time on a project and I find it has quite a severe limitation.

I have compiled a long list of features and scenarios written in the best given-when-then style.  I am gearing up for a specification workshop that will occur in a few weeks.  

What I have discovered is that it is really impossible to visualize the system from the features and scenarios.   All the examples I have seen of SbE are of systems that are well understood, such as an ATM.  It occurs to me that if you are designing a system that is novel, that is completely unique, then to try to collaborate among stakeholders using SbE is hopeless...like eating soup with a fork.  

What is needed in this situation is a narrative description of the system such as can be provided with use cases (ala Alistair Cockburn).   A use case (not to be confused with user story) is a type of story telling that describes a number of interaction paths through the system.  It engages our natural human ability to visualize a set of actors engaged in a narrative.

I'm trying to figure out if I can combine use cases with SbE, however they seem to be fundamentally incompatible.  A use case is a kind of script which is verboten in SbE.  I have been googling use case/SbE compatibility and have found nothing.

Regards,

Bob Rundle

  

[Gojko Adzic]

Bob,

I think you're mixing given-when-then and specification by example. it's trivially easy to do specification by example with use cases -- use case realisations are concrete examples of a case. you can apply the same heuristics to discover boundaries and structure and start a conversation with use case realisations as you can with any other example format, be it wireframes, given-when-then, calculation tables or flows. 

GWT is just one way of capturing the result of the conversation, there are many others. if it doesn't work for your situation, find some other way. 

> I have compiled a long list of features and scenarios written in the best given-when-then style.  I am gearing up for a specification workshop that will occur in a few weeks.  

this is completely the wrong order of things. given-when-then comes after the specification workshop, not before. what you've done is not spec by example, it's just analysis written down in a different style. a core aspect of spec by example is collaborative analysis (=workshop) that produces shared understanding, which can then be captured in some form with examples.

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 specificationbyexample+unsub...@googlegroups.com.
To post to this group, send email to specificationbyexample@googlegroups.com.
Visit this group at https://groups.google.com/group/specificationbyexample.
For more options, visit https://groups.google.com/d/optout.

[Bob Rundle]

Wrong order of things?  I thought SbE was the communications tool not the system-of-record tool.  What is the input to the specification workshop if not SbE?  I cannot show up with a empty whiteboard and a few markers.  Nothing will useful will come out of it.  

Anyway I have decided that use cases are not a reasonable approach either.   As argued in https://www.batimes.com/articles/user-stories-and-use-cases-dont-use-both.html, use cases are "BDUF - Big Design Up Front which is the antithesis of Agile"

To quote from your blue book: "The workshop starts with a business person, typically the product owner, business sponsor or an analyst, briefly describing a piece of software that needs to be developed."  The part that is apparently unspecified here is what "briefly described" means.  For a website, I can see that maybe a little hand waving is all that is required.  But I am building a complex system using advanced technologies that are cross disciplinary.  There will be perhaps 10 domain experts at the workshop representing areas that have little overlap.  I need to create an environment in which a common understanding of the system we are developing can emerge.  I was hoping (in vain apparently) that SbE would be the lingua franca of this effort.

So it would seem that a limitation of SbE is scale.  This might explain why my earlier observation that SbE seems to be only for web projects has gone unaddressed.

BR

[Gojko Adzic]

The input into the workshop is a few basic examples. the whole point of the workshop is to get to a shared agreement and understanding quickly, so if you need to spend a lot of time upfront to do your own analysis, that's pretty much defeating the point. spec by example isn't a tool for understanding scope of a five year project, it's a tool for shared understanding what a team needs to do over the next delivery cycle. if you have multiple teams, I'd hold sessions with each team individually.

in terms of scale, that really depends on what you measure. I've ran spec workshops with 30 people at a time. I've done it with major investment banks, working on developing financial asset management and transaction processing software systems, likely holding hundreds of millions of dollars under management of those systems, and it worked pretty well. 

gojko

--

[Anastasios]

Hi everyone,

Bob I think you’re exploring now, so a high level view would help. Impact or story mapping could help you If that’s your case.

~Tasso

Sent from my iPhone

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.

[Bob Rundle]

Exactly right.  I'm transitioning to User Story Mapping now.  I purchased Patton's book yesterday and I am about 25% of the way through it.  Great stuff.  I have already converted by big list of features/scenarios into user types/activities/stories, the backbone becomes visible and immediately I get a sense of the big picture.  This is what I will present at the specification workshop and iterate on with the domain experts.

Perhaps SbE still fits here downstream of story mapping.  The problem is that they don't seem to fit well together.  I have to change activities to features, scenarios to user stories and still it doesn't seem to mesh well.  Perhaps I will simply have to discard SbE all together.

Let me address one conceit that seems to be pervasive in all of these conversations about agile specification:  the idea that the spec writer (that is me) is some kind of glorified note taker that has zero understanding of the domain and simply copies down the wisdom of the domain experts.

In this case and in most every system I have worked on, I wrote the proposal (in this case my partner and I) for the system in question.  The domain experts are the customer who purchased the proposal.  Therefore by definition at the beginning of the specification process I am the foremost expert of what we are building.  To be successful I have to augment my limited understanding of the domain with the knowledge of the domain experts.  This is what I want to accomplish in the specification workshop and this is why I cannot walk into it with empty hands.  I have to have a draft specification that faithfully mirrors the system I sold them.  If I walk in with empty hands they will be wondering what they paid for.

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.

--
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 specificationbyexample+unsub...@googlegroups.com.