Second post mostly aimed at business owners. As the previous about why I won't sign your NDA, this is mainly a summary of experiences based on building various projects in the context of our upcoming MVP Labs (more on that later).

The Grim Situation

Software development is known to be pretty much a waste - as an industry, we are known to deliver late, badly and expensively. According to a McKinsey study, the mean software development project is 7% late, 56% over budget while delivering only 44% of the functionalities.

This is due to a lot of factors. One factor I want to clarify today is: "bad customer/developer communication" - and what you as a business owner can do to make my job easier.

The problem

Basically, we come from very different worlds. We both have our own jargon, expectations and implicit truths - as every business has. It means that explaining to me what you want is a very dangerous path:

• You'll withhold some information because "everyone" knows it (implicit knowledge)
• I'll misunderstand part of the rest, due to my own (flawed) vision of your business.

Complete Specifications

For years, we tried to solve this using more detailed specifications - up to thousands of pages. Although well intentioned, this did fail in a quite spectacular way for various reasons:

• Even writing do not prevent you of a bias
• I'll still miss some part of it (especially if it is big)
• The amount of work required to create it make the project both expensive and very late - before even starting
• By the time of writing the specifications, the request can again have changed.

While relevant in highly controlled environments, this process is most probably not what you want.

User Stories and Collaboration

Why User Stories?

The Agile movement advocated a different approach, less based on solving the user/developer communication mismatch and more on ways to cope with it. The basic assumptions are as follows:

• The bigger the functionality, the more complex it will be to describe/explain, the bigger the chance of misunderstanding
• The bigger the functionality, the longer the time it will take before it can be demonstrated (and validated)

Template

This leads to a simple (at least in its formulation) description:

• Try to keep features as small as possible (so the areas of possible misunderstandings are the smallest possible)
• Be sure that every single feature can be observed by a non technical user

The result of this is what we call a User Story - a simple template that describe a feature in a single sentence with the following format:

As a user category I want given feature so I can enjoy benefit

Some samples for a banking system:

• As a customer I want to be able to transfer money to another account so I can pay my providers
• As a customer I want to see my previous transfers to see where my money went
• As a customer I want to see an overview of all my account to get my balance in a single action

Benefits

As the format constrains you to a single sentence, it forces you to divide your big blocks into small ones. Not an easy process, but a very valuable one as the risk of misunderstanding becomes very low - and there is more:

• The story focusses on the user - who he is, what he wants and most important why (the benefit)
• As the story is "user observable", you'll have something to see/test after each story
• The simple format allows for easy agreement about whether something is done or not
• The small size allows to get a good vibe about the project process, as stories are typically developed in a couple of days.

Priorities

Once you have your list of stories ready, you can write them on post-its or their digital equivalent, Trello. You do not need all of them to start the project. With the first 5-10, you can start.

Now is the time to prioritize them, and the best way is a simple order: move the most important ones at the top, and work down.

Ready!

With this prioritized list in hand, you can come to a development team with a clear view of what you want. We'll typically run through the list together, asking any question we could have. Barring any technical reason to reorder (I may need to develop the user Sign Up story before being able to do for example Saved Filters), we'll then start working in order - taking the one from the top of the pile first.

Conclusion

Making my job easier is actually a good way to help me focus on what matters to you - hence delivering more value for your business.

Opinions? Let me know on LinkedIn!