How to tell a story about your experience

The IWST coordinators would like to encourage each workshop participant to prepare a presentation on:

  1. An experiential project report
  2. A problem-solving, decision-making opportunity
  3. Research findings and results
  4. A white paper or position paper related to the theme of the workshop

Experience reports (or other papers/presentations) should not blatantly advertise or attempt to sell products or services provided by you, your company, or your partners. We anticipate between 3 and 5 presentations will be given at a workshop, but the actual number of presentations is based on how much time the group decides to spend on each one. Some ERs last ten minutes, others last two hours. We stay with the ER as long as there is energy in the room. Guidelines for papers and presentations are located below.

Experience Reports

A good experience report has the following attributes. Attributes marked with an asterisk (*) are particularly important.

  • Describes an experience that you had first hand (not one you heard about, not about work the other team members did, and not an idea you only thought about). You will be expected to answer detailed questions about the experience from experts like yourself - without guessing, speculation, or "tap dancing."
  • * You feel strongly about the experience, the lessons you took from it (good or bad) and you want to share with an expert audience.
  • * The experience report is about a single experience, not a collection of related experiences.
  • The experience report describes the aspects of the experience that are relevant to the learning, such as:
    • technologies involved
    • business environment
    • people and their attributes
    • equipment and tools
    • details of the product or system
    • documents
    • data collection, results and analysis
    • sequences of events
    • relationship to the rest of the project
    • decisions made, why and when;
  • so that other people...
    • can compare it meaningfully with their own experience(s)
    • can evaluate your experience
    • receive enough information to suggest alternative choices you could have made in that situation.


Sometimes people aren't comfortable sharing an experience, or don't know how to effectively structure their experience in a way for attendees to get the most out of it. In those cases, it might be useful to try an interview presentation. This is where two people go before the group, and one attendee interviews the other (think of the classic Barbra Walters' style interview, only without the soft lighting and crying).

Your interview session should include these sections:

  • Who are you (both the interviewer and interviewee) in relation to your interview topic?
  • A list of questions designed to tell the story of the interviewee.
  • Questions that occur to the interviewer on the fly, which are asked in response to specific answers the interviewee provides.

Problem-Solving Opportunities

You can bring a specific problem for the group to work on and assist you with at IWST. While the main focus of IWST is sharing the lessons learned from experience, not all interests fit within the experience report format. Experience reports are necessarily backwards looking, and some issues will not be addressed if nobody in the group has previously encountered them. Much problem solving already happens on-line and off-line during the other IWST sessions, but these sessions provide a concentrated and facilitated brainstorming of your problem by the group. The sessions tackle common new challenges which group members are likely to encounter.

Your proposal for a problem-solving session should include these sections:

  • What your problem is.
  • Why this is a problem - what the risks and adverse consequences are.
  • What background information you need to provide for the group to fully understand the problem.
  • Why it is relevant and significant to the IWST group.
  • What decisions are needed and when.
  • What options or alternatives you have considered.
  • What your success criteria are.
  • What constraints an effective solution must comply with.
  • What progress if any you have already made.

Research Reports

A good research report has the following attributes. Attributes marked with an asterisk (*) are particularly important.

  • * Describes original research that you conducted or significantly participated in.
  • * Includes original data so other participants can draw conclusions or can check your conclusions.
  • Provides the details of how the research was conducted. The report should provide enough detail that readers could reproduce your results if given the same research environment. Specific details may include:
    • the starting hypothesis
    • methods used to collect data
    • data verification methods
    • technologies involved
    • equipment and tools
    • actual data, results and analysis
    • sequences of events
    • decisions made, why and when;
  • so that other people...
    • can compare it meaningfully with their own experience(s)
    • can evaluate your research
    • receive enough information to suggest follow-up research.

Position Papers

A good position paper has the following attributes. Attributes marked with an asterisk (*) are particularly important.

  • * Describes a position that you feel strongly about.
  • * Supported by research and/or experience (yours and/or others) that you have the ability to share with the audience.
  • Provides enough information for the audience to understand the basis of your opinion.
  • Presents your viewpoint as objectively as possible.
  • Likely to spark a lively discussion when presented. Lively discussions are permitted as long as they remain professional and relate to the position, not the presenter.
  • Be prepared (and able) to articulate why you have the view you do.


The following are the guidelines for the presentation of a paper or report at an IWST workshop. Guidelines marked with an asterisk (*) are particularly important.

  • * We prefer oral presentations presented informally (not a PowerPoint presentation). However, if you have *graphics* such as graphs, diagrams, or photographs, you can project them if you like. Please avoid slides with bulleted text - we find that they distract people from the experience report and increase the time needed to communicate the same content. We have found that this kind of information is better presented in the position paper or research report.
  • Presentations are delivered in the first person (i.e. "I did this...", "I saw that...") It is understood that you may not know everything about the project, but we request that you only speak of what you did and saw.
  • Data, diagrams and graphics should be presented in their native program where possible (i.e. spreadsheets shown directly in Excel, not copied into PowerPoint).
  • Data, diagrams and graphs may be discussed in detail.
  • If possible, be prepared to manipulate data and charts on the fly (i.e. "Can we make that a line chart instead of a bar chart so we can see if...")

Lightning Talks

We recently started trying the lightning talk format for some workshops. Sometimes we work them into longer workshops to break things up. We like this talk format for a couple of reasons:

  • it's a high-energy format
  • it gets everyone participating
  • you can explore a variety of angles on a topic in a limited amount of time

For a lightning talk,  participants should come prepared with at least one 5 minute lightning talk focused on the theme of the workshop. If there's not formal theme planned, it can be on any topic in software testing.

Each presenter will have 5 minutes for each talk. You can use slides if you like, or you can demo something live, or you can just get up and talk. After each talk, we'll leave another five minutes for questions. Then we move on. Each speaker will get ten minutes total. With permission, talks will be recorded for podcast.