How to Start New Agile Software Projects: Vision & Mapping

If you’re a technical leader overseeing the development of a greenfield software project, then you know how crucial it is to get the design right.

In this article and the next, we’ll explore how to approach the initial technical modeling of the system. We’ll look at some of the best practices for making critical decisions to establish an efficient development plan that will lead to maximum system quality and reliability. We’ll cover concepts such as the high-level characteristics of a system, user story maps, and what product roadmaps should look like.

This post is part of a series. Check out the other posts in How to Start New Agile Software Projects.

In a follow-up post later this week, we’ll also discuss how to evaluate risk and use that knowledge to plan the initial system architecture.

Identify Requirements

The path to an effective software solution is paved with untold perils, many of which are difficult to predict at the outset. The initial design phase allows us to identify some potential roadblocks and work around them, but it must be undertaken with care and be effective.

I usually rely on the following artifacts to identify and delineate the project’s requirements:

Vision Statement

The project needs to stay focused on a goal, and you need to communicate that goal. It is a concise statement that outlines the direction and long-term objective of the project to the team and stakeholders.

Here’s a quick example:

To create an intuitive system for knowledge workers to consume and curate technical content so that they can absorb and share knowledge about new technologies as quickly as possible.

During the project’s lifecycle, that vision statement will guide decision-making and the development of the roadmap.

High-level user story map

The user story map is a visual representation of the user’s journey through the various components that compose a system. It takes a bit of practice to achieve the right level of granularity, but the result is quite valuable.

It can be assembled on a whiteboard, with the horizontal axis representing the flow of the user’s journey and the vertical axis representing the different components that compose the system.

Use cards or post-its to represent a hierarchy of stories associated with each of the system’s users’ activities. It’s essential to focus on only the more important stories and activities that are best aligned with your vision statement to keep things manageable at this stage.

You can find an excellent guide to creating user story maps on the Lucidchart blog.

I’m a big fan of user story maps because they are an excellent example of human-centered design that promotes usability and is easy for the team and stakeholders alike to understand.

Short product roadmap

During the initial planning, having a precise roadmap focused on individual features or components is usually a waste of time. After all, no plan survives contact with the enemy.

A more helpful type of roadmap focuses exclusively on providing specific user outcomes. The goal of the initial roadmap should be to provide a structured user-focused refinement of the vision statement that the team can use to determine the technical needs of each milestone.

While there is some overlap between this type of roadmap and the user story map, the roadmap is more concise and is a more helpful tool for decision-makers, so they both have their place during project planning when establishing a shared vision for development.

Translating Maps into Architectures

In my next blog post, I will show how to translate these user story maps and roadmaps into actionable choices about system architecture for a project. It is vital to lay the groundwork for system design decisions and to keep the right perspectives in mind, as discussed in this article. Still, the way that this translates into real choices about system architecture is another topic entirely.