User stories, luvvies and conveying project scope

We get sent a lot of ideas for apps; mobile and web based. Sometimes we get the most amazingly detailed documents that give us a thorough understanding of what the idea is and what it’s supposed to achieve.

Inevitably this is the exception to the rule, as being from different industries most people know what  they want yet find it difficult to know the best way to describe it and miss out large chunks that are important to us. In the NLP world this is known as “deletion”. We all do it; “pass me that”, we delete the reference assuming that whoever we are talking to knows what we’re on about.

When we get job referrals like this, at the expense of possibly losing the project we ask the potential client to clarify their idea with two specific processes. This also helps us determine if they are serious about the project.

1. What’s the essence of the idea? This is essentially the elevator pitch.
2. User stories. What platforms and users are involved and what can they do. We call this the “stage” and actors.

The five minute elevator pitch

Distilling the essence of an idea into a single sentence is a really great way to communicate your project succinctly. A nice template to get this up and running quickly is as follows:

• For [target customer]
• who [statement of need or opportunity]
• the [product name]
• is a [product category]
• that [key benefit, compelling reason to buy].
• Unlike [primary competitive alternative]
• our product [statement of primary differentiation].

For teams and businesses who need to keep track of their contacts the ContactZilla platform is a contact management solution that is completely social. Unlike Sugar CRM our product merges contacts from social media and traditional sources effortlessly.

Just this one statement helps with our understanding in a really big way. It’s quite a fun exercise too. We originally discovered this in the book “The Agile Samurai“.

User Stories

User stories are a pragmatic way to get a project communicated effectively. Essentially you are describing what the application should do for particular types of user and while not telling the developer how to do it. This means you don’t have to keep asking “is it possible?” you just state what is needed. The developer then needs to figure out how; with the resources available.

Project managers will weep that we ask a prospective client to come up with user stories. It is such a simple way to convey interactions, goals and functionality that even if done badly it’s usually more helpful… (we can argue about that in the comments)

First you need to identify the “stage”, this is a simple theatre metaphor that a lot of people understand straight away – the stages in a lot of cases can be an administrative area and a public facing area. We then need to identify the “actors”. These are the different types of luvvie people interacting on your stages. For example an administrator, a guest visitor, a bronze user, etc. This then leads to the user stories themselves.

As an [actor], I can [feature] so that [reason]

As an Administrator, I can delete a blog post so that I can keep things tidy.

You may find that you don’t need the reason, so get rid of it.

As an Administrator, I can delete a blog post.

If we now combine this with the stages we can break up the user stories into sections;

Administration Area – Managing Users

As an Administrator I can delete a user

As an Administrator I can send a message to a user

My profile page

As a logged in user I can update my profile picture

As a logged in user I can change my biography

You can take this much further as a project manager and a development team but for the sake of simplicity this gives a client a really good starting point to convey what they want to achieve in a succinct format.

We find that most clients find this a really rewarding process, it focuses them on what they want to achieve as opposed to how to achieve it. In some cases it also demonstrates the complexity of what it is they want and either validates or invalidates their idea. Which we can all agree is best done early.

Conclusion

Using these two simple techniques helps both parties enormously. It’s not always necessary and doesn’t need to be an extensive exercise but just enough to ensure a level of understanding on the side of the development, project management and sales team (after all its hard to quote for something you don’t understand).