Process Overview

In the last section we gave you an overview of what all this Agile stuff is really about, which can be summarized as the continuous delivery of working, valuable software.

In this section we are going to take a deep dive into the planning process, describing exactly how you can plan a successful software project using Agile methodologies. Each subsequent chapter will detail a specific stage in the process.

Where Does This Fit?

Before we get too far into the weeds, let's take a brief moment to discuss where the planning process fits into the whole of the Agile process ecosystem.

In general, Agile methodologies are focused on injecting feedback loops into the building process. It does this by incorporating lessons learned into subsequent iterations of building a product, an idea, a piece of code, or a team.

In a software organizations, these might take the form of 4 primary feedback loops which are detailed in the image below:

We don't want to get you too confused with the other cycles but here are very brief overviews if you want to learn more about these parts of the Agile process.

Business Cycle

At the highest level is the corporate vision or company direction iteration. The timeline of this iteration could range from several months for a new start-up to several years for a larger, more established company. The crux of this iteration is that an organization will form a mission around a marketable product or service, they will attempt to deliver value to the market, and market feedback will determine future direction.

A start up may enter the market with a specific idea, build various prototypes to gain traction but ultimately find that their business model needs to change or pivot for them to be successful. Similarly, a more established company may make a multi-year investment in a certain business line, and its performance over a few years will lead to its continued funding, abandonment or modification.

Planning Cycle

The rest of this book will focus this part, the planning cycle. We are going to go over all the steps related to the purple boxes.

For any solution that the organization envisions, there may be several planning cycles that create a set of features and deliver them in releases to end users. Those people most familiar with the market, generally the product managers and user experts, will leverage data and experiments to find out what users want (which is typically not the same as what users "tell" you that they want.) These exercises can result in a set of prototypical users called personas and a set of hypotheses on what solutions would be able to satisfy their needs.

Once a set of product features are delivered, the team measures how users respond and validate their hypotheses about user preferences and behavior. This information lets the product designers suggest features that are more suited to the user needs.

Release Cycle

Once product designers have determined a feature set that needs to be built to provide user value, the next iterative process is the planning of a release to deliver a set of working software. This is called the Software Release iteration. In the Agile model of software development, we rarely, if ever deliver everything at once to a user base. This would mean there was a lot of up-front planning and a ton of assumptions made with no validation. In the release iteration, we portion off a set of the most important features of the total solution and create a plan around delivering this set.

Sprint Cycle

The last main cycle is where the bulk of software development gets done! The sprint cycle usually occurs during a time frame of 2 to 4 weeks. At this level the feedback is as much about the work process and team members as it is about the product development. At the beginning, the teams plan their work for the length of the sprint, coordinate their efforts to complete it in priority order, and end the sprint by reviewing what went well and could be improved.

Notice that multiple sprint cycles make up a release cycle, and multiple release cycles can make up a planning cycle; finally, multiple planning cycles may take place during the long term rotation of the business cycle.

Let's Focus

Now that you know what part of the larger process we will focus on, and the general ideas around the rest of the process, it's time to drill down on an overview of the key planning cycle processes.

What we want to do is take the ideas through the planning process until they are broken down, with sufficient detail to build the application. We'll leave the actual building and measuring feedback up to you.

The above image shows the steps we will follow in order. If you look at the tree, follow the orange boxes. Our examples will follow this orange box path. Some things to note about the tree:

• At each step in the planning process, you typically come up with multiple answers to the output requirements. In the image above for example, one Concept results in creating two personas.
• As a result, this tree starts to branch out more and more the farther you get in the process.
• This is OK because once we get to the "leaves" of this tree, we will have lots of little requirements that will help us execute building the software.
• For our examples, we will try to follow one line of discussion, one trunk or branch, so you can see how each step feeds into the next.

The stages of the planning process are as follows:

Application concept

Determine your application concept. What is the problem you are trying to solve? How are you planning to solve it? What's the mission, the goal? How might it look? Keep this stage really high level.

Developing Personas

Who uses your concept? What does a typical user act like? What are their needs? How does the user influence our designs? Here you will create people, of your own design, that might use your software.

Writing Scenarios

How does a user actually accomplish a goal? What does it look like when they use your software to solve their problem? What do they access, upload, share, do? Write narrative elements here to describe real use scenarios.

Storyboarding and Wireframes

Time to bring the scenarios to life. Storyboarding here can be helpful in illustrating interactions, wireframes can show rough user interfaces, sets of user interfaces can walk people through the app concepts.

Writing Epics

Break down the larger narrative scenarios into shorter parts of the story known as epics. Each epic solves a smaller user goal, they are informed by the storyboards and wireframes.

Breaking Down Epics to Stories

Each epic is too big to build at once. Break down each epic into the smallest components of an application, a user story. These are focused on delivering just a little bit of user value. Together they form the product backlog that is used to build the actual software.

Remember It's A Cycle

It's important to remember through this process that it is part of a cycle, and also that it is continuous. You may come up with more Personas along the way, and you may always be adding new epics and stories to describe new features.

We are going to describe each of these steps as if you are starting from scratch, but remember you can always jump back into any stage of the cycle to add more to your application, incorporating all that you learned in previous rotations of the cycle.

Let's get into it by taking a simple application concept and breaking it down into personas in the next chapter!