Having worked on a multitude of software projects in the past 10 years, our team has adopted a workflow which we believe allows us to achieve peak efficiency. By following this workflow we are able to continuously deliver value to our clients, starting on the very first week of work.

The workflow is simple. It’s composed of two phases: Inception and Development.

This is the first of a series of posts where I will describe these two phases, along with a few important practices we use on each of them.

In this post, I will describe the first phase, Inception. Albeit being the less technical of the two phases, we strongly believe this is the most productive way to gather requirements and, most importantly, collectively build a vision for the project.

Inception

When we start a new project, we always start with the Inception phase. This is an essential phase for every software project, regardless of the platform the project will be deployed on (mobile, web, etc.). The goal of the Inception is to identify, as a team, the problem we are trying to solve and how we plan to get there.

The Inception phase brings together a combination of agile techniques for capturing requirements such as User Story Mapping and Product Backlog Building. It typically takes one to three days of meeting, involving representatives from the development team, stakeholders, and a facilitator who is responsible for driving the meeting and taking notes.

The artifacts of the Inception phase are as follows:

1- Vision Statement

2- Product Backlog

3- Wireframes

Vision Statement

Before we can start writing code, it is imperative to understand the problem we are trying to solve. Surprisingly, this is the first trap most software projects fall victim to: failing to identify the problem landscape and coding towards the wrong solution.

“Failing to identify the problem landscape and coding towards the wrong goal is the first trap most projects fall victim to”

We believe assumptions can only be proven through working software and real users. The goal of the Vision Statement is to write down the current assumptions, determine personas involved and those who would benefit from the solution, and other competitors in the market.

The final Vision Statement document includes answers to the following:

1- What problems are we aiming to solve ?

2- Who are we helping ?

3- What benefits should the solution bring ?

4- Who are the competitors, or similar solutions ?

With these answers in hand, we are able to move towards the next artifact of the Inception phase: the Product Backlog.

Product Backlog

The initial Product Backlog contains a comprehensive, but not exhaustive, list of User Stories associated with their corresponding goals and personas. The backlog also indicates precisely which User Stories should be included on the first release of the project.

The following image is an example of a recent product backlog we’ve created together with one of our clients.

Product Backlog

The Product Backlog is the source of truth for our story cards. These cards are entries in our project management software, used by the team to keep track of the tasks being worked on.

The story cards themselves are not involved in the Inception phase so I’ll be covering them in more detail in an upcoming post.

The other important feature of the Product Backlog is the ability to determine which features should be included in the first release, also known as the Minimum Viable Product (MVP). On the previous image, notice the bold line after row 21. Using the frequency, importance and priority assigned to each User Story, we are quickly able to determine which features will help us prove our assumptions right or wrong by being included in the MVP.

With the Vision Statement and Product Backlog in hand, we are ready to work on the last artifact of this phase: Wireframes.

Wireframes

Low fidelity drawings serve not only as a way to identify the initial visual elements of the application, but also help as driver for communication.

Having elements to point at allows us to start aligning expectations such as number of “clicks”, necessity of a “scroll”, elements available for “typing” and whatnot. This is particularly important for mobile projects, where real estate is scarce and must be used conservatively.

Since our team is fully remote, we currently use a web-based collaborative wireframe tool called Balsamiq, and have also successfully used GoMockingbird in the past.

The image bellow is an example of a wireframe for one of our internal mobile projects:

GarageWODS Wireframe

The final product is available for download in the AppStore, so check it out! When you do so, you will notice there are a few differences between the wireframes and the final product. This is not only ok, but also expected. We do not anticipate the wireframes to picture exactly what the final version of the project will look like, but rather serve as a guide to determine which elements and interactions are important to reach the solution we want.

Conclusion

In this post we described the first phase of our project workflow, Inception. In this phase, we gather requirements and collectively build the vision for the product. The artifacts from the Inception include the Vision statement, Product Backlog and Wireframes, which are all used by the team to build and release the many versions of the project, allowing us to prove (right or wrong) assumptions through working software and real users.