Spec by-example

SPECIFICATION BY EXAMPLE

Looking for the source of the truth

Specification by Example• Key benefits:

– Less rework– Higher product quality– Implementing changes more efficiently– Better alignment of the activities of different roles

• Key Practices:– Deriving scope from goals– Specify collaboratively– Illustrating using examples– Refining the specification– Automation validation– Evolving a living documentation system

Specification by example

• Understand better the goals of the system• Building a living documentation of the system• Maintaining a constant source of the truth• Validating the system often in order to ensure

the functionality• To describe the system in a way so that it is

easy to add features.

Deriving scope from goals

• F16 should fly at 2 to 2.5M (requirement)• F16 should be able to scape from combat

(goal)GOAL1

REQ1

REQ2

REQ3

GOAL2

StrategyNeedsCompetitivenessSolution to

Implement:

A requirement use to be a direct answer to a specific goal


• Ask for the goals using the requirements• Be clear about the goals when the

requirements are defined.• Refine your requirements in the context of the

goals not other requirements• If you have any doubt, don’t be fooled, ask for

the right person .


• “The hardest single part of building a software system is deciding precisely what to build.” – Fred Brooks, The Mythical Man-Month: Essays on Software

Engineering (Addison-Wesley, 1975)

• “People tell you what they think they need, and by asking them “Why” you can identify new implicit goals they have. Many organizations aren’t able to specify their business goals explicitly. However, once you derived the goals, you should again reverse and derive scope from the identified goals, potentially discarding the originally assumed scope.”– Christian Hassa


Received scope

Adressesed goals

Derived scope

WHY DO YOU NEED THAT?

COLLABORATIVE SOLUTION

Challenging requirements is always part of the solution model

EXERCISE 1

• The system should persist my shopping cart for 1-2 weeks

• The system should be able to send me a copy of my shopping cart

• The system should alert if any of the prices has changed in the articles of my shopping cart.

• The shopping cart should appear always when the user logs in.


• As Stakeholder (WHO)• In order to achieve some goal (WHY)• I need some system function (HOW)

Advice: Use this form for deriving scope from goals

Specify collaboratively

• Different teams in different context have their own way of collaborating.– Find your own way!– Discover how to make efficient conventions!– Always look for improvements in your way!

• Of course I am talking about cross-functional-teams.

Specify collaboratelly

“Specification workshops are intensive, hands-on domain and scope exploration exercises that ensure that the implementation team, business stakeholders, and domain experts build a consistent, shared understanding of what the system should do”– Gojko Adzic. “Specification by Example: How

Successful Teams Deliver the Right Software.”

EXERCISE 2

• Let’s make a kite.


• Workshop goals– To find the technical constraints (feasibility)– To find the business constraints (boundaries)– To address the solution targets (goals) – To build a common vocabulary– To use the right examples for specifications– To establish a safety network of knowledge and

later refinement.

Specify collaboratelly• Prepare the workshop beforehand.• Record the event for further referencing.• Business use to drive but others can raise some insights.

• Clasify the topics:– Not in scope– To further investigation– Not easy feasible– High importance

• Outcome: – write a document with some conclusions.– Create a follow up agenda– Next steps


• Smaller workshops (three amigos)– A tester– A developer– A Business analyst

Outcome: AcceptanceCriteria Narratives

16

Be sensitive to your user task’s “altitude”

© Jeff Patton, all rights reserved, www.AgileProductDesign.com

* from Cockburn’s Writing Effective Use Cases

Functional or “Sea level”I’d reasonably expect to complete this in a single sitting

Sub-Functional or “Fish level”Small tasks that by themselves don’t mean much. I’ll do several of these before I reach a functional level goal

Activity or “Kite level”Longer term goals often with no precise ending. I’ll perform several functional tasks in the context of an activity

Too abstract

Too detailed

Think about user experience at this

level


• Find the right examples to illustrate a feature• Use the examples as drivers in a specification

workshop• Write out those examples for further

reference.• Use the domain vocabulary around the

examples.• Examples are easy to understand and share.


Refination meetings:• Acceptance criteria write down. (peers)• Acceptance criteria review. (seniors)• Batching questions. (business)• Key conversations use your documentation tool for

collect it.• Planning meetings. (testers, developers)• Elephant Carpaccio & Story mapping

– http://agileproductdesign.com/writing/how_you_slice_it.pdf– http://alistair.cockburn.us/Elephant+Carpaccio+Exercise

http://agileproductdesign.com/writing/how_you_slice_it.pdf

http://alistair.cockburn.us/Elephant+Carpaccio+Exercise

19

The user story map contains two important anatomical features

• The backbone of the application is the list of essential activities the application supports

• The walking skeleton is the software we build that supports the least number of necessary tasks across the full span of user experience


time

nece

ssity

The backbone

The walking skeleton

20

Given story map organized vertically by necessity, we need only slice to plan

• Choose coherent groups of features that consider the span of business functionality and user activities

• Support all necessary activities with the first release• Improve activity support and add additional activities with subsequent releases


time

optio

nalit

y

necessary

lessoptional

moreoptional

first release

second release

third release

Exercise 3

• Slice the shopping cart epic from user stories to tasks

• Review it against another group (win to win)• User story mapping to release the shopping

cart product incrementally• Outcome: the final acceptance criteria for the

first release.

Illustrating using examples

• “Illustrating requirements using examples is a way to specify how we expect the system to work with enough detail that we can check that assertion. Examples used to illustrate requirements are good black-box tests.”– Gojko Adzic. “Specification by Example: How

Successful Teams Deliver the Right Software.”


• Examples spot inconsistencies– Free delivery example

• Examples spot ambiguities– Free for everyone!

• Examples helps to dive in the user story– When to send an email?

• Examples shows boundaries– Who is NOT able to receive this loan


• Examples should be complete


• Examples should be realistic– Avoid making up data– If possible use real data– Extract examples from the organization– Or clients!

I am not good as an example


• Use examples for non functional requirements– Performance targets should be precise– Resiliency only has a meaning with examples

• Use examples to find the boundaries– Technical exclusions– Warning messages– Actions after push to the limits

• Use mockups to illustrate your examples.


• The paradigmatic example (example of examples)– https://en.wikipedia.org/wiki/Tests_of_general_re

lativity

• Good examples capture expectations and business concepts.

https://en.wikipedia.org/wiki/Tests_of_general_relativity

https://en.wikipedia.org/wiki/Tests_of_general_relativity

Refining the specification

“In its rough form, a diamond is a lusterless, translucent crystal that resembles a chip of broken glass. For it to be transformed into a jewel, it must be cut into a particular gem shape and then polished, facet by facet.”

– Edward Jay Epstein, The Diamond Invention


• From raw examples to Acceptance tests• Focused, Precise and Testable• About business functionality, not software

design• Should document what the system does, no

more.• Where were the S.M.A.R.T. requirements?– Those are coming from Management by Objectives

– Peter Drucker 1.981


• Free delivery example• Bad examples are more frequent than good

ones– Scripts are not specifications– Technical oriented language is a bad sympton– Describe what the system does not imply dense

user-system flow.– But still should be executable.– Merciless refination


• Self exploratory– Use Inputs and outputs as behaviour expectation– Use a title and a description paragraph– Specify the actor and the goal to achieve– Try to understand it in the context of a regression

test fail.– Ask another person if she understands the

specification.

Exercise 4

• The shopping basket revisited– Refine our specification– Add a new functionality


• A good specification should contain tipically– Key examples of each important part of the

business functionality.– An example of each important technical edge case

or boundary conditions.– An example of each particular troublesome area

of the expected implmentation.

• Over-specify has always a bad smell


• Self-explanatory• Use the domain language• Use given-when-then narrative aka Gherkin• Focused in a single aspect• Do not try to over specify (refine instead)• Use the happy path to enable the automation

pipeline.

Automating validation

Spec by-example

Software

Transcript of Spec by-example