Proudly sponsored by: wanted: Product Placement Sponsor wanted: Publishing Sponsor wanted: Sponsor 2 wanted: Sponsor 3 wanted: Workshop Sponsor
managing expectations - a blook for mastering agile requirements

2011 Agile Alliance Functional Test Tool Workshop

Posted in Uncategorized on June 12th, 2011 by admin – Be the first to comment

Announcing the 2011 Agile Alliance Functional Test Tool (AA-FTT) Workshop: a community gathering to network, learn, and collaborate about Acceptance Test Driven Development (ATDD) on Agile projects. We aim to strengthen community connections with the hope of continued adoption and advancements in ATDD. We welcome practitioners (analysts, developers, testers, managers) of all experience levels (beginner -> advanced, skeptic -> advocate).

Date: Sunday August 7, 2011

Time: 9:00 AM – 5:00 PM

Location: Grand America Hotel, Salt Lake City, Utah (co-located with Agile 2011 conference)

Format: Openspace (self organized event where the agenda is developed collaboratively based on he interests of the participants)

Cost: No charge

Lunch: Provided by AAFTT Program

Facilitator: Ainsley Nies

We are now accepting registrations at As with our previous workshops, the cost for attending is $0. You will, however, have to pay your own travel costs.

Registration is required in order to plan for the catering. Once you register, you will receive an email with final details about schedule and location.

Did you like this? Share it:

ATDD Pattern Workshop Summary

Posted in Uncategorized on January 16th, 2011 by admin – 1 Comment

As the AAFTT community continues to share ideas about tool support for Acceptance Test Driven Development (ATDD), we notice that a shift is taking place. Discussions on the yahoo group and at the 2010 workshop in Orlando branched out to also include things like: the ATDD process and workflow, adopting ATDD, and addressing our ambiguous terminology.

One way we want to explore these topics is by developing a pattern language to capture the successful ways that teams balance the forces affecting the adoption and practice of ATDD within different contexts. The initial pattern language workshops (full day October 1, 2010 in London, England, and an abbreviated intro/writers workshop demo in October 6, 2010 in Berlin Germany) will start to establish the architecture of the pattern language, and produce some initial draft patterns.

This is the first step in growing a pattern language, a process that always takes time and requires community involvement and commitment throughout. We will be holding subsequent workshops to refine the pattern language architecture, and focus on completing specific patterns within the language.

This post provides a summary of the activities and outcomes that we produced in these initial sessions. A follow up post will provide an initial glimpse as to the current vision for the next steps for collaboratively creating the ATDD community of practice pattern language.

(text in red is a place holder for missing information  … participants, please contact me with updates)


(missing: links to their blog post of the event)

October 1, 2010 London, England:  Gojko Adzic, Jennitta Andrea, Laurent Bossavit, Mario Cardinal, David Evans, Steve Freeman, Markus Gaertner, Elisabeth Hendrickson, Jez Humble, Liz Keogh, Antony Marcano, Chris Matts, Linda Rising (facilitator), Joseph Wilk

October 6, 2010 Berlin, Germany:  Gojko Adzic, Jennitta Andrea, Lisa Crispin, David Evans, Markus Gaertner, Janet Gregory, Janne Härkönen, Elisabeth Hendrickson, Juha Rantanen, Linda Rising (facilitator)


Create an initial architecture for a pattern language to capture the successful ways that teams balance the forces affecting the adoption and practice of ATDD within different contexts, start writing some of the patterns, workshop some of the patterns, plan for the on-going work on the pattern language


(London only) Jennitta led a discussion about the scope of the ATDD pattern language, using these slides as reference.


 Linda presented the following:

Brainstorm Architecture

(London only) We spent a short time individually brainstorming patterns (one pattern per sticky note). Then we re-assembled to share our ideas and collectively group them into affinity groups by virtue of which flip chart page they were placed on, and how they were clustered with other sticky notes. This is a very early start to our pattern language architecture. The interesting thing to reflect on is the breadth of topics that were brought up by this diverse group.<links to photos> 

 The sticky notes & flip charts were transcribed into a spreadsheet:

  • Each worksheet = one flip chart sheet
  • Each row = cluster of related sticky notes
  • Each cell = one sticky note (name, contributor, short summary)

Write Patterns

(London only) We had about 45 minutes to select one of the sticky notes and write as much of the pattern as possible (given the standard pattern template that we just learned. The patterns do not have names yet – they are listed here by their initial aliases.

  • Elisabeth Hendrickson & Liz Keogh: Breaking the model. Context questioning. Should it really?
  • Markus Gaertner: Essential Examples
  • ???: Get it wrong
  • David Evans & Gojko Adzic: Feature-set hierarchy, break down story documentation after implementation, regression suire, feature documentation
  • Jez Humble: Scenario-based tests, regression suite, curated acceptance suite, the Ottomans (also attributed to David Rice, Martin Fowler, Ben Butler-Cole, Jeff Rogers)
  • Mario Cardinal, Chris Matts: Illustrating with Examples, Illustrate user stories with Examples, Concrete over abstract
  • Jennitta Andrea: Big picture, process tracability

<missing patterns by Laurent Bossavit, Steve Freeman, Antony Marcano, Joseph Wilk>

Workshop patterns

Video and transcription of demo workshop held in Berlin.

Did you like this? Share it:

def’n 4: “Managing Expectations”

Posted in commentary on September 19th, 2010 by admin – Be the first to comment

“Managing Expectations” is a blook focusing on the agile requirements practice Acceptance Test Driven Development (ATDD). A lead by example approach is taken (couldn’t resist another multiple-entendre). As a real-world project* is built step-by-step using an ATDD approach, the relevant book contents are driven out in tandem to ultimately cover:

  • The full ATDD workflow.
  • A=RDVRTF (agile = regularly delivering valuable running and tested features).
  • The system-effect ATDD has on the other practices.
  • Critical success factors for ATDD, and hence agile as a whole.
  • Meaningful tool comparisons through expressing the expectations for the project with a variety of different ATDD tools.
  • *A community website for collaboratively ranking ATTD tools (this is the real-world project we are building).

“Managing Expectations” is different from other books because the writing and publishing process directly reflects agile values. It is considered a blook (yes that’s an L … not a typo) because it is a complete book published incrementally to the Internet and is freely and permanently available to readers. It is an engaging experience for the reader, as they are able to provide feedback and participate in discussion with the author and other readers every step of the way. Readers are able to influence the order and emphasis of the content. The example is built through collaboration with other respected luminaries within the field using a variety of different tools to provide rich, multi-dimensional, and valuable content.

Next time, I’ll give you a tour of how the different parts of the blook work together, and the business model that it is based upon. Then we should be ready to jump right in.

Did you like this? Share it:

Foundations of Agile Software Development – 1 day tutorial spots available

Posted in announcements on September 16th, 2010 by admin – 2 Comments

Pass it on … there’s only a few spots left for my one day tutorial  Foundations of Agile Software Development at Agile Testing Days, Berlin.  

Wondering what agile is all about? Skeptical that agile is the same old thing wrapped in new buzz words? Tried agile on a project with disappointing results? You need a solid foundation of what it really means to develop software using an agile approach. Regardless of the brand name, a successful agile project is easily recognized by its outcomes: delivering valuable, running, tested features on a regular basis.

During this full day tutorial Jennitta Andrea explores each component of this definition in detail, looking at how specific practices and role collaboration work synergistically to achieve the goal. This foundation enables you to create a personal roadmap of agile topics to pursue during this conference and beyond and for introducing agile to your organization. More importantly, your foundation is rock-solid because you will understand how project context influences decisions about selecting and adapting an agile process.

My writing style and teaching styles are similar.  The concepts are brought to life by incorporating memorable every-day anecdotes, engaging hands-on activities, real-world examples from my extensive hands-on experience, and practical context-sensitive advice.

Agile Testing Days, Berlin is going to be an exciting conference.  Hope see you there. 

Summary slides   have now been posted.  Of course, this is the foundation of the content of the Managing-Expectations blook, so stay tuned here as well.

Did you like this? Share it:

Critical Success Factors of ATDD – 2010 World Tour

Posted in announcements on September 6th, 2010 by admin – Be the first to comment

I’m excited about my new presentation Critical Success Factors of Acceptance-Test Driven Development (ATDD)

A good analyst or tester knows what questions to ask to quickly bring clarity to a murky subject. When they first hear about Acceptance Test-Driven Development (ATDD), a core practice on agile projects, their initial questions often are “Can examples really capture functional requirements?”, “Where do user stories come from?”, and “Will the analyst and tester roles become extinct?” When Jennitta Andrea worked on her first agile project in 2000, she asked all of these questions and more. As a hands-on practitioner and keen observer of teams and processes on more than a dozen agile projects since then, Jennitta has discovered that success comes from knowing how ATDD fits within an ecosystem of roles, practices, and tools. Learn what Acceptance Test-Driven Development is, the critical success factors for ATDD, and the details of several key success factors.

I will take  this presentation on a “world-tour” over the next few months, starting tomorrow:

Sep 7, 2010 Calgary Calgary Agile Method User’s Group (CAMUG)
Sep 21, 2010 Calgary Software Quality Discussion Group (SQDG)
Oct 4, 2010 Berlin Agile Testing Days Conference (within my one day tutorial)
Oct 18, 2010 Edmonton BA World Conference
Nov 18, 2010 Orlando Agile Development Practices Conference

Hope to see you at one or more of these venues. 

Summary slides have now been posted.  Of course, this is the core content of the Managing-Expectations blook, so stay tuned here as well.

Did you like this? Share it:

def’n 3: *managing* Expectations

Posted in commentary on August 28th, 2010 by admin – Be the first to comment

Understanding ATDD and getting good at it is only half the battle. Many of the critical success factors are ultimately in the hands of “Management”: decision makers responsible for key things like project priorities, schedule/scope/cost tradeoffs, staffing, training, tool selection, and process adaptation. At the recent AA-FTT community of practice retrospective, many practitioners and coaches reported a variety of roadblocks to getting widespread acceptance of ATDD on their agile projects (Craig Smith’s summary blog captured some of these discussions nicely).

Software processes are like an ecosystem; all of the components—activities, practices, roles, workflows, tempo, tools, and work products—depend upon and enable each other in complex and unexpected ways. This blook demonstrates the key role that ATDD plays within the agile process ecosystem to enable teams to regularly deliver valuable running and tested features (see “ATDD is not as Optional as you Think” for a preview). Clear roadmaps and context-driven decision aids are included in the blook to facilitate the changes teams must make in order to fully succeed (the changes are highlighted in my chapter of the Beautiful Testing book).

Supporting “Management” decisions is critical for ATDD to take firm root.

Did you like this? Share it:

def’n 2: managing *Expectations*

Posted in commentary on August 26th, 2010 by admin – Be the first to comment

On agile projects that practice Acceptance Test Driven Development (ATDD), the term Expectation [1] refers to a concrete elaboration of a functional requirement. This blook fully embraces this meaning of the term managing Expectations with the primary aim of helping practitioners manage (write, organize, automate, maintain) Expectations on their agile projects, and thereby incrementally build a Requirements asset that will be valuable for the entire life of the project. 

NOTE: Other terms are also widely used to express this same concept: Examples, Behaviors, Story Tests, Acceptance Tests, and Functional Tests.   One of the first things a good analyst does when they encounter overloaded terminology is to clarify the meaning of the terms in order to eliminate both kinds of hidden ambiguity: 

  • Violent agreement: When different terms are used for the same concept artificial disagreements arise because both parties do not recognize they are actually saying the same thing. 
  • Hidden disagreement: When the same term is used to refer to different concepts, both parties believe they are in agreement when in fact they are not.

For this reason, a group of practitioners developed the TDD Triangle during an open space session at the 2008 Agile Alliance Functional Testing Tools program workshop.

A Requirement is a general statement describing how the system is expected to behave (aka feature or business rules), expressed in the vocabulary of the business domain. Requirements are anchoring points for ATDD.  For example, in the domain of a video store point-of-sale system, one requirement is:

 The Catalogue contains the list of all unique Movie Titles that the Video Store currently offers for purchase or rental.

An Expectation elaborates a Requirement with concrete explanations of how the system will behave under specific conditions. Expectations are expressed in the vocabulary of the business domain, and typically have a three-part structure: precondition + action = post condition, often expressed in the form, “Given the system is in state X when we do Y, we expect the outcome to be Z.” The following Expectations elaborate the video store requirement:

  Success Expectation Given the Movie Title “Star Wars” is not already in the Catalogue, when we add it, then we expect Star Wars to be available in the Catalogue.

 Duplicate Error Expectation Given the Movie Title “Star Wars” is already in the Catalogue, when we add it, then we expect a Duplicate Movie Title Error.

 A Test is the act of executing an Expectation against the real system to confirm the requirement has been met. A test can be run many times, each of which is a record of what happened during a particular execution, for example:

 Duplicate Error Example passed on July 2, 2009 with build 1.3 in the Qual environment.

An Expectation can be used as a test, but not all tests are Expectations (e.g., nonfunctional or exploratory tests). The shift is subtle: an Expectation becomes a test when it is executed, but first and foremost the purpose of an Expectation is to elaborate the Requirement.

The community of practitioners continues to strive to find the right terms to use about the actions and artifacts associated with this process.   This blook will support the standardized terminology as it evolves.

[1] I acknowledge Elisabeth Hendrickson for introducing me to the term ‘Expectation’ (not sure if she is also credited with coining it).  I first heard her use this term during the AAFTT workshop in Oct 2007.  At the time I interpreted this to mean the post-condition or  ‘expected results’ section of a test.  I finally understood her more generalized meaning of this phrase in April 2009 while we were planning the 3rd annual AAFTT workshop.

Did you like this? Share it:

def’n 1: managing expectations

Posted in commentary on August 25th, 2010 by admin – 1 Comment

The common use of the term ‘managing expectations’ refers to aligning unrealistic hopes/beliefs with reality.

Despite its overall level of maturity, the agile community continues to confuse agile requirements with testing and/or user stories. These types of misconceptions have spurred me to write this blook.  Over many years I have consistently written articles, presented at conferences, and taught courses on the topic of Agile Requirements.  Some highly esteemed peers within the agile community still associate my work with user stories or testing, leaving me feeling completely misunderstood.

Misconception 1: Agile is the same old thing wrapped in new buzz wordsRegardless of the brand name, a successful Agile project is easily recognized by its outcomes: delivering valuable, running, tested features on a regular basis.   Within this blook I will elaborate on each word of this definition as well as the synergy of the whole.

Misconception 2: Agile Requirements = user stories.  User stories are fundamentally a part of the planning process, and are merely a ‘ticket’ into the requirements process (“a promise for a conversation”).

Misconception 3: Agile Requirements = testing. Agile requirements aim to be highly trustworthy specifications.  This is accomplished by elaborating the business requirements with concrete examples, and by making these examples executable to have an objective and obvious indicator when the specification and the system are out of synch. Because they are automated, and because they are part of a practice called ‘test driven development’, most people confuse this activity with ‘testing’.

 This blook aims to have a broad reach within the community with the aim of addressing these misconceptions and guiding the community to a clearer understanding of the differences and synergies between user stories, agile requirements, and agile testing.

Did you like this? Share it:

Quadruple Entendre

Posted in commentary on August 23rd, 2010 by admin – Be the first to comment

The title Managing Expectations was intentionally chosen for this blook because of the multiple meanings associated with the phrase, depending on which word is emphasized.

  1. managing expectations
  2. managing Expectations
  3. managing Expectations
  4. “Managing Expectations”

Each variation will be described in the next sequence of posts.

Did you like this? Share it:

Under Construction

Posted in announcements on December 30th, 2009 by admin – Be the first to comment

The Managing Expectations Blook will be unveiled in 2010.  Watch here, Linked-In, and Twitter, etc for updates and announcements.

Did you like this? Share it:

Proudly sponsored by: wanted: Product Placement Sponsor wanted: Publishing Sponsor wanted: Sponsor 2 wanted: Sponsor 3 wanted: Workshop Sponsor