Exploration Through Example

Example-driven development, Agile testing, context-driven testing, Agile programming, Ruby, and other things of interest to Brian Marick
191.8 167.2 186.2 183.6 184.0 183.2 184.6

Mon, 21 Nov 2005

Story card style

I've been corresponding with Rachel Davies about story card style. She said something wise. Here's a slightly edited version of the correspondence (with her permission).

It all began when I asked a question about the "As a [role], I want [ability], so that [benefit]" style of writing stories. (See Mike Cohn's User Stories Applied for a description.)

Rachel:

Incidentally, I dropped this story format about 2 years ago because it encourages people to think of story cards as mini requirements documents and encourages the grumpy refrain "but it says on the card". I now encourage teams to write only the story name with a marker pen in large caps on 6x4 unlined index cards (easier to read by people standing around planning table or board) because this encourages conversation to continue during the iteration.

Me:

Interesting. What now encourages focus on the benefit and person who benefits?

Rachel:

I agree that novice teams need to be encouraged to ask their customer about this information in the planning game. I recommend using a checklist for each story (do we understand business value, story beneficiary, acceptance test). However, if this information all gets transcribed onto the card then developers just read from the card during the iteration and even if the customer is sitting nearby they don't tend to ask questions. If you leave only the story name on the card then the developers are forced to replay the conversations with the customer (which is a good thing).

## Posted at 09:38 in category /agile [permalink] [top]

Two oblique commentaries on abuse

Not all Americans wanted to [treat prisoners well]. Always some dark spirits wished to visit the same cruelties on the British and Hessians that had been inflicted on American captives. But Washington's example carried growing weight, more so than his written orders and prohibitions. He often reminded his men that they were an army of liberty and freedom, and that the rights of humanity for which they were fighting should extend even to their enemies. Washington and his officers were keenly aware that the war was a contest for popular opinion, but they did not think in terms of 'images' or 'messages' in the manner of a modern journalist or politician. Their thinking was more substantive. The esteem of others was important to them mainly because they believed that victory would come only if they deserved to win. Even in the most urgent moments of the war, these men were concerned about ethical questions in the Revolution.

David Hackett Fischer, Washington's Crossing, p. 276


Confirmation bias is a phenomenon wherein decision makers have been shown to actively seek out and assign more weight to evidence that confirms their hypothesis, and ignore or underweight evidence that could disconfirm their hypothesis [...]

Among the first to investigate this phenomenon was Wason (1960), whose subjects were presented with three numbers (a triple):

2 4 6

and told that triple conforms to a particular rule. They were then asked to discover the rule by generating their own triples and use the feedback they received from the experimenter. Every time the subject generated a triple, the experimenter would indicate whether the triple conformed to the rule (right) or not (wrong). The subjects were told that once they were sure of the correctness of their hypothesized rule, they should announce the rule.

While the actual rule was simply "any ascending sequence," the subjects seemed to have a great deal of difficulty in inducing it, often announcing rules that were far more complex than the correct rule. More interestingly, the subjects seemed to only test "positive" examples; that is, triples that subjects believed would conform to their rule and thus confirm their hypothesis. What the subjects did not do was attempt to falsify their hypotheses by testing triples that they believed would not conform to their rule.

Confirmation Bias, Wikipedia.

In an October 2002 speech in Cincinnati, for example, President Bush said: "We've learned that Iraq has trained al Qaeda members in bomb-making and poisons and gases." Other senior administration officials, including Secretary of State Colin L. Powell in a speech to the United Nations, made similar assertions. Al-Libi's statements were the foundation of all of them.

Al Qaeda-Iraq Link Recanted, Washington Post, July 31, 2004.

According to CIA sources, Ibn al Shaykh al Libbi, after two weeks of enhanced interrogation, made statements that were designed to tell the interrogators what they wanted to hear. Sources say Al Libbi had been subjected to each of the progressively harsher techniques in turn and finally broke after being water boarded and then left to stand naked in his cold cell overnight where he was doused with cold water at regular intervals.

His statements became part of the basis for the Bush administration claims that Iraq trained al Qaeda members to use biochemical weapons. Sources tell ABC that it was later established that al Libbi had no knowledge of such training or weapons and fabricated the statements because he was terrified of further harsh treatment.

CIA's Harsh Interrogation Techniques Described, ABC News, Nov. 18, 2005.

## Posted at 09:15 in category /misc [permalink] [top]

About Brian Marick
I consult mainly on Agile software development, with a special focus on how testing fits in.

Contact me here: marick@exampler.com.

 

Syndication

 

Agile Testing Directions
Introduction
Tests and examples
Technology-facing programmer support
Business-facing team support
Business-facing product critiques
Technology-facing product critiques
Testers on agile projects
Postscript

Permalink to this list

 

Working your way out of the automated GUI testing tarpit
  1. Three ways of writing the same test
  2. A test should deduce its setup path
  3. Convert the suite one failure at a time
  4. You should be able to get to any page in one step
  5. Extract fast tests about single pages
  6. Link checking without clicking on links
  7. Workflow tests remain GUI tests
Permalink to this list

 

Design-Driven Test-Driven Design
Creating a test
Making it (barely) run
Views and presenters appear
Hooking up the real GUI

 

Popular Articles
A roadmap for testing on an agile project: When consulting on testing in Agile projects, I like to call this plan "what I'm biased toward."

Tacit knowledge: Experts often have no theory of their work. They simply perform skillfully.

Process and personality: Every article on methodology implicitly begins "Let's talk about me."

 

Related Weblogs

Wayne Allen
James Bach
Laurent Bossavit
William Caputo
Mike Clark
Rachel Davies
Esther Derby
Michael Feathers
Developer Testing
Chad Fowler
Martin Fowler
Alan Francis
Elisabeth Hendrickson
Grig Gheorghiu
Andy Hunt
Ben Hyde
Ron Jeffries
Jonathan Kohl
Dave Liebreich
Jeff Patton
Bret Pettichord
Hiring Johanna Rothman
Managing Johanna Rothman
Kevin Rutherford
Christian Sepulveda
James Shore
Jeff Sutherland
Pragmatic Dave Thomas
Glenn Vanderburg
Greg Vaughn
Eugene Wallingford
Jim Weirich

 

Where to Find Me


Software Practice Advancement

 

Archives
All of 2006
All of 2005
All of 2004
All of 2003

 

Join!

Agile Alliance Logo