How to Write a Successful Experience Report Conference Proposal

I'm reviewing experience report proposals for the XP 2023 conference. While I see potential in many of these proposals, I don't see enough proposals that make me say, “Yes! I want to read this report! And see the speaker!” (Yes, I react in exclamation marks when I read a terrific proposal.)

Experience reports allow us to learn from each other, from the successes and the failures and everything in between. And experience reports tell the story of those experiences. Here are three necessary pieces for successful experience report proposals that make me react in exclamation marks:

  1. A successful experience report proposal has two stories: what happened in the organization and your story, as the experiencer and writer.
  2. Write your proposal so the program committee can see both of those stories.
  3. Remember that your first audience is the program committee.

I'll take each of these in order.

Tell Two Stories in Your Proposal

Experience reports tell two stories: the greater story of the experience and your story. I like to think of the greater story as what occurred with the desired outcome. That might be for the organization or a specific product or project. Your story, as the writer and experiencer, explains how you learned and changed during the experience on the way to that outcome.

For example, I've collaborated on two writing experience reports. The first was Mike Griffith's and my experience writing the Agile Practice Guide. See Bridging Mindsets: Creating the PMI Agile Practice Guide.

The second was with Mark Kilby and how we wrote our book. See You Have to Say More There: Effective Communication in a Distributed Agile Team.

In both cases, we told two stories in one report. The first story contained the greater experience of the writing project and its ups and down. The second story was how each of us learned and evolved as we proceeded with those projects.

The program committee needs to see both of those experiences in the proposal. As you consider your experience, think about the larger story of how the organization, project, or product changed. Then, remember to add your story, what you learned, and the impact of that learning.

When you include both stories, the program committee can see what is special about your experience. We can get excited about your proposal. But we need to see the stories.

How to Organize a Story

Often, experience reports tell these stories in chronological order. That means each story has a start, a middle, and an end.

  1. The initial state: What did you first see that prompted this experience? Was there a problem? An opportunity?
  2. Then the meat of the story, where you explain how you chose alternatives.
    • Which things did you try in which order, and what happened? Think of those things as try/fails or try/succeeds.
      • People tried something that had some outcome. Was that outcome a “failure” where you considered new alternatives? Was that outcome a success where you built on that success and proceeded to the next experiment?
      • What did you measure? Did you change any measurements?
      • How did people react and learn? How did you react and learn?
    • When did you notice successes or failures? When did you change course?
  3. The current/end state. What did you and people learn? How did you and the people evolve or change?

That's the structure of an experience report.

For a proposal, the program committee needs to see enough detail that they have a reason to say yes. If you don't write down enough detail, it's too easy for the committee to say no.

So your first audience is the program committee.

Explain the Experience to the Program Committee

The program committee is the gatekeeper for the conference. That means they need to see enough of the experience to be able to judge the two stories: the organization's or greater story and your story.

Consider having a paragraph for each of the three points above. I particularly like OneStartlingSentence for the first paragraph, so the program committee understands why you started this effort.

Next, program committees need to see the structure of the story, so they can see the unique perspective you bring to the experience report track. Then, the try/fails and try/succeeds. In the proposal, you don't need to write paragraphs. Bullets will do for now. When you write the paper, you'll add in all the delightful detail.

Next is the story of how you and the people changed or learned (or did not). Again, a few bullets will do. This is the next place you will show what's unique about your experience.

Finally, the end state. While I learn from people's successes, I also learn from their failures. We have too few failure experience reports, and INMHO, we would be better as an industry if we had more of them. Include how long the organization has succeeded or failed. (There's a reason so many organizations can only use agile approaches at the team level.)

Iterate on your proposal until it's done. Once you have a proposal that explains both stories (in bullets), now you can edit. Check for typos, etc.

As a final check, do you have roughly four paragraphs that describe the story? If you don't, you might not have enough to help the program team say yes.

Help the Program Team Say Yes

Use these ideas to write your successful experience report proposal. Make me, an experience report reviewer, want to work with you and read your report.

Include all the pieces above, even if you put them in a different order. I can't guarantee the program committee will say yes, but show them everything they need to know. Good luck!

I wrote a whole series about conference proposals, starting with Create a Conference Proposal the Conference Wants, Part 1. I also wrote a book: Write a Conference Proposal.

This blog post expands on the ideas in that book.

2 thoughts on “How to Write a Successful Experience Report Conference Proposal”

  1. Hello, I’m bringing these questions I already made on Twitter at your request so all your readers can also benefit from the answers.

    1) Is there a good approach to share a real case without unveiling non-shareable details (you know, those protected under an NDA, or that can point to someone, etc)?

    2) I can’t find incentives for a speaker to explain a failure. It’s not a good advertisement for finding clients and it’s another excuse to receive hate or bad feedback. How can the Agile community protect these speakers?

    Let me thank you again for your kind answers.

    1. Jose, thanks!

      1. Writers can always anonymize their writing for both the company and the people. Here are several ways:
      • Anonymize the company by using a fake name, such as “Acme Corp.” You might also consider “Fortune 100” or “small startup” or “mid-growth or mid-level org.” Do categorize the company so readers understand the context, but you don’t need to name the company.
      • Anonymize the people. Change the person’s gender and name. I tend to use common names, such as Jane or John, unless the person has a common name. Then I use Cliff or Clive or Maude or Mandy.

      Now, from a position of empathy, explain the situation that catches these people and why you tried/considered various interventions. I highly recommend pictures.

      IME, no one will recognize themselves in your story. That’s because they rarely recognize their system. Even if they do recognize their system, they will appreciate your empathy with them.

      1. Re incentives for writing about failures:
      • Always start with empathy for the people and their context (especially if you think they made bone-headed decisions). Then try this:
    2. Explain how the ppl meant well.

    3. Explain your possible interventions and what occurred
    4. Go meta and explain the system. <— this is where people can appreciate “failures.”
    5. For the system, explain the next steps.
    6. You will get clients if you can explain the system. I like to reframe “fail fast” to “learn early.” IME, current and potential clients would all like to learn early. You might add something like this: “In the future, we could learn earlier with” and then add more interventions, etc.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.