Some collected advice and learning after doing Agile Conference submissions for a while. The main aim here is to get a session accepted because we believe we have something important to add to the agile discussion. But we also need to sell the importance of our session. Some of this learning is based on “what seemed to work” but since the submission system is a bit like black box these observations might have been the result of “coincidence” as opposed to any scientific analysis, so please treat accordingly.
Have a catchy name for the session, something that pokes fun or is a little controversial. This helps not only in capturing the interest of the reviewers, but makes it more memorable when it comes time for the reviewers to determine who will be presenting. And it will help when the conference attendees are thinking about which session to attend.
From past experience we have learned that proposing a single session significantly reduces your chance of being accepted. So we proposed 3 this time. This is just playing the odds and is based on talking to people that did get accepted - most had submitted more than one.
From past experience level of discussion associated with an entry is no indicator of likely acceptance. First time I was accepted there was no input. Second one had a lot of people commenting, and saying things like “good subject” but it was not accepted.
Work offline, work collaboratively. Take a copy of the headings on the submission page and put them of something like a wiki page so you can work with others on the submission. Track changes made, especially the big ones as a result of comments so there is an understanding of the history but, more importantly, serves as fodder when you build the presentation. Some ideas may not make sense as part of the submission but that does not mean they don't help with the overall story. If you have access to someone to collaborate, use that connection. Trust me when I say “you will end up with better content”.
Read the Agile web site instructions. I've been submitting for a few years, but what I found is that the use of the proposal system has changed a little over that time. For example, the abstract is now more aimed at what the conference goer will see and respond to as opposed to being an abstract for the submission process. As such I was making it too long. I could have figured this out by reading the instructions a little closer instead of assuming I knew what was going on.
Read the section on what the stage is about, specifically the questions they see the stage is addressing and then craft you submission so you address a few of those items explicitly. Having been on the “reviewer” side it is pretty sad when you get something that hasn't been thought through wrt the stage it is being presented from.
The section called “information for reviewers” is where you put the details of the presentation. This is where you talk about the background, and how you expect to use your time. Most of the time workshops seem to be more acceptable than pure presentations unless you are a keynote speaker so try to make the learning experiential.
Don't overload the section on “learning”. Reality is that people can really only learn a few things in a given period of the time, and the people reviewing the submissions often know this. It is better to have a couple of concise ideas of what people can expect from the session than it is to have large number of general ideas. It also helps you focus your presentation and so should be seen as a tool. The title needs to grab. Its the first thing that people see. Don't be afraid to tweak the title to reflect what is going on.
The first paragraph of the abstract needs to capture people's interest as most people will only read the first paragraph when at the show. And your reviewers know this.
End result - 1 presentation accepted out of 3 submitted, as we expected for the year I wrote this.