Measure Twice Code Once

Measure Twice Code Once

I often tell people I work in software development and get the response “So, you code?”. It seems the outside world doesn’t realize that much like a carpenter, the planning and measurement is just as (if not more important) than the cut.

At Echobind, we spend a significant amount of time planning before a single line of code is written. We have made it part of our playbook. We utilize various processes and tools to understand what the business goal is, how we will measure success, and what the features will actually look like. Then we take all of this and wrap it together to create a comprehensive document that describes the project in perfect detail.

We start with our discovery session. We use a client questionnaire and a kickoff meeting to start gathering the “why” of the project. We use this as a fact-finding mission asking questions that from our experience steer the conversation toward the true business goals. We then gather up every possible feature imaginable. Once we have our feature list and business goals we go to work. Matching every feature to a business goal we move them to must-have, nice to have, and phase 2. Once we have this we get moving on a user flow. A schematic of the application showing every which way we could go once we open it up. At the end of this, we have the makings of a true MVP.

After discovery, we move to wireframes. We go through the process of designs and revisions, discussion and iteration. We refine what is needed and set the rest to the side. Once this is done we have a clickable prototype of exactly what we plan to build.

Now that we have everything this project is going to be we piece it all together. This is our business requirements document. It takes all the knowledge that has been gathered since the first engagement to the final wireframe and puts it together into a single comprehensive document. This will have everything from business goals and key performance indicators to risks and technical needs. We use annotated wireframes to describe exactly what each feature does and the actions that can be taken.

The apex of our planning comes in the form of this document. We use this to estimate the cost of the application. We are able to go feature by feature and understand what is needed at a granular level. This also provides an opportunity to work with our clients to cut scope when needed. The idea is that I can take the business requirements document and hand it to anyone and they will be able to read it and know exactly what we are building. In the end, we have a full plan on what to build and how to do it that could be given to any agency with faith they should be able to build it including ours.

Our strategy team has found planning in this much detail and working this much upfront saves buckets of money. Changes during engineering are the most expensive and with this document, they become nearly negligible. Business and engineering can all agree on what we are building from a single document. No translation needed. This is why we measure as many times as it takes before we make that first cut.