Designing software solutions can be a complex and challenging process that requires careful planning and collaboration. Balancing the needs of all stakeholders while ensuring the project will be on time and on budget can be very tricky.

Lets explore how to approach solution architecture in a team environment, focusing on the importance of collaboration and streamlining the process to flow into Agile project management.

There are a few key deliverables of the solutions architecture process, which are:

• Documenting the end user requirements. The solution needs to actually solve the problem it is looking to address.
• Documenting the solution. This is the most important aspect of solutions architecture, but the solution only comes after the problem domain is properly defined. Getting #1 right first is the key to everything.
• Documenting the agreed scope of the project. Defining the scope ahead of time helps prevent scope creep.
• Documenting the project backlog. If done right, the project backlog comes for free and I will show you how.

An often overlooked aspect of designing the solution is planning the project to build the solution. To streamline the process, the output of the solutions architecture phase should flow directly into the Scrum/Agile project management workflow.

Each step in the project lifecycle flows into another, so it’s important to keep this in mind. Typically, the project lifecycle will look something like this, with the requirements gathering and solution being the first step:

The output of the solutions architecture process should be directly translatable into the next step in the process, defining the project backlog. Which is then used to define the project scope and plan the delivery of the project (via project sprints).

Start at the high level and slowly drill down into the details. If you start with specific requirements and a lot of detail, you will quickly have an incomprehensible mess of requirements to sift through. Keep it simple and start with the big stuff.

The first step is to define the top-level components of the project. What are the big pieces we need to address to solve our problem? These top-level components should approximately map to epics in Agile project management terminology.

For example, if you were building a homepage for your site, one top-level component might be building the subscribe form.

The next step is to define the tasks required to build this component. These tasks should approximately map to user stories or tasks in Agile project management terminology.

For example, your subscribe form will need an email entry field, a submit button, and an integration into your email platform. These are your tasks or user stories.

The next step is to break down these tasks into their exact requirements. These requirements will become the definition of “done” for the user story/task. Typically, these can be dropped into the user story ticket description.

If you don’t know the exact solution or requirement, you can capture this by defining a blocker or an unknown. These can be followed up later, but by capturing them they won’t be forgotten, and you can maintain velocity in the process.

The best way to represent this plan is visually, with each epic/task/requirement defined using different colored cards. If you’re doing this with pen and paper, you can use post-it notes or index cards. Or you can write it up on a whiteboard. Whatever works for your team.

Using different colors is important; it helps visually differentiate each type. Something like this:

The epic, stories, and requirements should be stacked vertically, as you drill down into the details. Start with the epic at the top. Have each user story/task underneath the epic. Then have requirements for each task directly underneath that.

Using our subscribe form epic as an example, you might map out the solution something like this:

This solution mind map can then be easily translated into the project backlog. In Jira, this would look something like this:

In reality, solutions architecture is an iterative and collaborative process. It includes the architect, engineers, end users, and other stakeholders. You won’t get it right the first time; it will take at least a few attempts to get it right. But with the right approach, the process will be a lot smoother, and everyone will be on the same page.