When I moved to a new job and discovered they were using Google Docs to write functional specs I was…shocked. This was a nimble, fast-moving company that was winning awards for its apps. Surely they weren’t using word-processing tools to design their features? Big documents that list out the behaviour for a software feature seemed so un-agile.

I’m pleased to admit that I was wrong.

Writing functional specs for your project is a more agile way of designing software, and will result in a more focused team and better quality product.

More agile

Writing down exactly how your software should work forces you to confront potential complexities or inconsistencies in a much more agile fashion than many other practices, because it is so easy and cheap to adapt once you start getting feedback. They’re only words after all.

More focus

Writing down exactly why you’re building the software forces you to focus only on the features that are important to your goal, and gives the development team a ‘North Star’ to follow when making technical decisions.

Better quality

Writing down exactly what your software will do forces you to tackle the specifics that can otherwise so confidently hand-waved away. It is easy for everyone to agree “and then the user receives an email with a confirmation of their booking”, but it’s not until you have to write it down that you realise you also have to decide what the text of that email should actually be.

Specs at the right time

Of course as with all software projects, the key is getting the right level of detail at the right time. I am not advocating you open up Google Docs on Day 1 of a project and start writing detailed scenarios and edge cases and other kinds of product whataboutery. However on Day 1 you probably should write down the core goal of the project, and a summary of the background that’s led you to this point (e.g. why this goal is important). Then, as you move through your discovery and research, you begin fleshing out the spec with your learnings, slowly creating a skeleton for the project. Ultimately you will flesh it out with specific details, but not until development is just about to start - i.e. at the right time.