The Event Success Management methodology doesn't draw directly from the Agile Manifesto. Instead, it's based on lean thinking, where the agile movement also finds its roots. However, the core concept is borrowed from the agile approach. At the heart of Event Success Management is the desire to delight the participant with a meaningful event worth their time. The event should be produced with a minimum amount of blood, sweat, and tears wrung from the event organiser. If you compare this with the principles behind the Agile Manifesto, I bet you can see the resemblance.
Agile user stories in event planning
Let's look at what agile practices we could use to make an event a success. The most widespread planning method in agile software development is the user story. The agile movement adopted the approach from Extreme Programming, where all developable functionalities in software are described from the end user's perspective, using their voice.
In general, the user might say something like: I want to do X to get Y benefit.
Sounds simple, but recognising user roles is often challenging, and understanding what they want to say (instead of working as the product developer's ventriloquist's dummy) can be even more complicated.
In Event Success Management, we're mainly interested in two prominent roles or users: the event organiser and the event participant. Both of these roles have their particular desires that we can study with the help of user stories.
Say we're organising a two-day seminar about Event Success Management. We can start studying this from the organiser's perspective as that is the role we're most familiar with.
The event organiser could say for example:
- As an event organiser, I want to hold a seminar to establish myself as a thought leader in Event Success Management.
- As an event organiser, I want to hold a seminar to widen and deepen the understanding of Event Success Management practices.
- As an event organiser, I want to hold a seminar to build a society of Event Success Management professionals.
The above "stories" describe the goals that the event organiser wants to achieve. In the context of this event's user stories, they are huge, epically big. Epic user stories mean that they are too big to realise as simple stories and can be broken down so that we can discover the value in meaningful chunks. Let's try.
- As an event organiser, I want to give lecturers a unique role in my event to showcase them as exemplars of the community.
- As an event organiser, I want to give all the participants wearable tokens to visually identify the event community.
- As an event organiser, I want to book a powerful and evocative speaker to give an opening note to build the emotional connection between the attendees.
- As an event organiser, I want to guide my opening speaker to build the community to have that programme building community.
If you test this, you can see how easy it is to develop stories for the role you are most familiar with. It becomes a bit trickier when you start thinking about the user stories of your event participants - who they are and what they want.
Breaking down the participant user story
There are different kinds of participants for each event. Even if you organise an event for event management professionals, you might have in-house event organisers, event management consultants and event management students participating in your event. As an event organiser, you want to know who they are so that you can study their stories and make your event fit the participants’ needs as neatly as possible.
According to the practices of agile, you should start by outlining the possible user stories.
- As an event professional, I want to participate in this seminar to learn Event Success Management from the official program.
- As an event professional, I want to participate in this seminar to network with my peers from other companies.
- As an event professional, I want to participate in this seminar to get new ideas from fellow event pros.
- As an event professional, I want to participate in this seminar to make some name for me by speaking at the seminar.
When you have made the first breakdown, further dissect the stories for the relevant roles. Let’s focus on one of the examples: As an event management professional, I want to make a name by holding a speech.
Now, break it down into sub-stories to make the story come to life:
- I want to pitch my speech to the organiser, to get a chance at having the spotlight.
- I want to negotiate the place of my speech in the programme so that I get to go to my favourite shows.
- As a selected speaker, I want to get my slides to the seminar system so that I don’t have to hassle with my computer on the big day.
- As a selected speaker, I want the seminar programme to advertise my appearance in an appealing way to attract good attendance.
You get the idea. Many things make it worth the speaker’s time to attend the seminar in this role. If the speaker is someone the organiser wants to attract, we create an appealing win-win by thinking about their needs and desires.
So, what to do with the seemingly endless amount of stories you end up with? When software is developed, there is always more to do than what we have time for. Only about 20% of features in a given system are helpful to the customer using it. That is why we have to prioritise the things we do because ideally, we won’t be developing more than that 20%. The same goes with the event example. When you have many stories, you prioritise them by seeing what kind of a participant experience the stories together would seem to promise. We simplify the stories, taking bites out of them that seem to offer the best and shared value.
And what’s next? Like old mama panda used to say: that is a story for another night.