Did some stories, did some code mining, did a feature walkthrough (so they know where they’re going). Talked about what scenario testing is and what the role of testing is on projects. They’ve already found a big stack of bugs in the existing code.

Synopsis of their discussion of scenario testing:
Got through the demo and started trying to figure out things for tomorrow — came up with some programming tasks. Cem pulled the group back and suggested that they should ask whether any of them would want to use this product (even after doing some of the tasks) and figure out how they would approach answering the question. Cem suggested having a couple of people go off and learn a lot about blogs and blog features and who the appropriate customer for the tool is, then appraise the tool to determine where it is and where it isn’t. This led to discussion about whether the testing group sits as a service organization to the programming team or to the customers. They also talked about the technical tasks that a testing group performs that are out of the scope for the customers (bugs that customers will never imagine, tools the customer will never create, but which testers would find/create). This got cut off by time. Key moment (according to James): Mike said the reason there is a customer representative in an XP group is to have one concrete answer. This caused a concerned murmur from the testers, and served as an anchor point for the discussion. The tester serves as a source of light to illuminate customer decisions and other decisions the customer might want to make. Since testers are not primarily focused on designing and building the project, they’re freed up to look for potential problems and inconsistencies in case the customer rep does not fully represent the issues of the entire community. James sees programmers as primary client — all things good come from the programmers. Cem talked about how a key part of agile development is untraining the busy work from the testers and retraining them in how to be do more productive stuff

We had some interesting discussion about the planning game. Some people felt the planning game took too long (particularly given the time scale of this project), others (who weren’t used to XP planning games felt it took far less time than what they were familiar). Mike H. felt it was long because there were things that he would have liked to talk about later on, suggestions of more breaks and spreading the planning game out over the course of several days were also brought up. BC suggested that some of the stress came from our unvoiced assumptions conflicting together. Mike would prefer to let the assumptions float and deal with them when someone is about to code the story. Mike F. suggested spike time between story generation and estimation.
3 groups of people needing representation on project:

• Stakeholders — anyone impacted by product (includes end users)
• Stakeholdes with influence — stakeholders with power to influence design (includes anti-stakeholders, such as hackers)
• Representative

Cat food analogy — the people who buy the cat food don’t eat it, so most of the money goes into the packaging and not the contents of the can. Cats have traits that serves as reasoning for why they don’t like food. For software, the buyers don’t use it and if the users don’t like it, while they’re just finicky users.

Subtitling heuristic — Translate “No user would do that” as “No user that I can think of that I like would try to do that” What about hackers, accidents, that kind of thing?

Agency law — effectively reflecting someone else’s point of view

We began a list of things to do tonight:

• Anderson-style brainstorming styles of doing automated acceptance tests for HTML based applications
• Learn FIT
• Learn shams
• Discussion of the role of testing
• Discussion of difference between customer representative and stakeholder community