The 5 Levels of Agile Planning

These planning levels were originally described by Hubert Smits in the whitepaper 5 Levels of Agile Planning: From Enterprise Product Vision to Team Stand-up. We provide below, some key highlights for each level of planning.

1. Vision

Before creating your vision statement, we must focus on the customer by identifying the roles that will be interacting with the product. This step will help better understand the customer and will help in writing user stories based on these roles. Another technique to consider at this stage is to associate personas for each role. These personas will help the team humanize the work and ensure that they write test scripts for different types of users, that go beyond the obvious user experience.

The simplest way to capture your vision is to use the Elevator Pitch format from Geoffrey Moore’s template from Crossing the Chasm:

FOR (target customer)
WHO (statement of the need or opportunity)
THE (product name) is a (product category)
THAT (key benefit, compelling reason to buy)
UNLIKE (primary competitive alternative)
OUR PRODUCT (statement of primary differentiation)

2. Roadmap

With the Vision published and accepted by all, the Roadmap will serve as the next building block to ensure alignment to the original Vision. This Roadmap is meant to be used as a tool to organize high-level pieces of the product. These can be business features and/or architectural components that must be understood in terms of their value and dependencies. These pieces must be organized over a period of time and the most typical way is to maintain a rolling four-quarter view of the work. Every time a quarter (or whatever dimension is used) ends, the Roadmap must be updated for the next four quarters.

3. Release

Instead of writing detailed requirements for the entire Roadmap, this next level of planning only focuses on the upcoming release, which corresponds to a quarter, or whatever dimension used in your Roadmap. The goal of the release is to produce a backlog of work that is represented by a list of user stories that are estimated, prioritized, and ordered.

Stories – work written as user stories with acceptance criteria, and they are ordered by feature, themes or various groupings to help visualize the work
Estimates – all the stories have a relative sizing, typically using story points that include design, development, and testing.
Plan – the prioritized work based on value, fits with the capacity of the team(s) assigned to this release

Integration Testing

Integration testing is usually the earliest actual testing that can find integration bugs (although review processes can find some bugs before the software is written, or before the code goes to test). You want to find these bugs before you start showing the software to the product owner or you release it, since fixing bugs at the last moment is very expensive. You want to find these bugs earlier in the process when they would be cheaper to fix because you need multiple working components to integrate (by definition). Integration testing–ensures that the units are working together in concert. This is mainly to test your design. If something breaks here, you have to adjust your unit tests to make sure it doesn’t happen again.

Releasable Software

Once a feature is complete and all the testing has passed for that feature, then it is deemed Releasable Software. The key in Agile, when we talk about being faster time to market, has everything to do with shipping completed work as soon as possible, instead of waiting until the end of the project. There are a few clarifications needed here…

A completed feature can be one or many stories, but it doesn’t necessarily mean that all the stories associated with that feature are delivered. This is why we do release planning, we want to force brutal prioritization every release in order to focus on Minimal Marketable Features (MMF) or Minimal Viable Product (MVP). The best time to negotiate what is absolutely required in a release, is at the beginning of the release, not once the release started, or even worse by not having any release planning.
A feature fully tested means that the team and organization have agreed on the Definition of Done for testing before the software can releasable. There are many types of testing applicable to a specific time and environment to test. For example, we expect Unit Testing and Behavior Testing to be Done during the iteration. We also expect other types of testing like Accessibility, Front End Performance, Middleware Performance, Security, Load Testing and Web Consistency to be included at the iteration or release level. The key is to have an agreement on what type of testing and when they will be performed so that we ensure that the software is releasable as soon as it’s ready to ship.

4. Iteration

An iterative approach simply means that the work is time-boxed into a set length of time. The ideal iteration length is 2 weeks, any longer than this will most likely cause the business side to disrupt the iteration by adding/changing the content of iteration, the planning and review ceremonies in Scrum to take longer, and procrastination to naturally creep in.

From a testing standpoint, all the work planned in the iteration must be tested, in order to embrace the Agile value of focusing on working software. This means that the team will need to test first by embracing TDD (Test Driven Development) and ultimately BDD (Behavior Driven Development). These techniques promote full team collaboration during planning and designing during the iteration in order to define the test case and build the test scripts. As we will describe in the next two sections, it will be very important to write good user stories and include clear acceptance criteria.

Stories

User stories are expressed from the perspective of the person who will be using the feature/capability and therefore should provide what is needed to test that the user will be able to complete the action. It typically follows this simple template:

As a <user>, I can<activity>, so that <business value>.

As a <WHO>, I can <WHAT>, so that <WHY>.

It’s important to note that stories are not the same as requirements. Where requirements try to lock in every possible scenario upfront and often provide details on how to accomplish the work, the user story instead does not mention the HOW. The best way to describe a story is to view it as a “vehicle for conversation” as explained in the Three C’s from Ron Jeffries, more specifically, the intent is for people to ask questions and capture the confirmation of these conversations as acceptance criteria, in the user story.

Acceptance Criteria

These cover the boundaries of the story and will serve as scenarios for writing the test cases. Once the story is written or during story writing, it’s important to capture acceptance criteria and make sure that an acceptance criteria is not actually a story and vice versa. The acceptance criteria do not expand the story, it strictly provides the scenario behind a story, in order to write good test cases. Acceptance criteria should ideally be written using the Given-When-Then formula, in terms of scenarios and implemented as classes:

Given [initial context], when [event occurs], then [ensure some outcomes].

There are some types of stories that benefit from creating a checklist for items to look for in a story. For example, creating forms and reports are notorious for having missing or changing acceptance criteria once the iteration starts.

For forms, it’s important to understand which fields are mandatory, what are the validation rules and where exactly the form will be submitted.
For reports, the focus is on what are the inputs/outputs for the report, for example, what fields are needed to generate the report, what are the columns to show on the report, is the column sortable and/or filterable?

The goal is to make sure to capture the right level of acceptance criteria, these should not turn into dumping what used to be your requirements under a story. The acceptance criteria should not tell you how to do the work, but instead how to accept and test the work. They serve as the key for teams to know before they start working, what will be considered acceptable. Some organization refers to these as success criteria, which re-enforces their importance, as the team fully understand what it will take to be successful at the story level.

Automated Build

Many companies make the mistake of building and testing their code possibly on a daily but more likely on a weekly basis, this leaves too much room for defects to creep in while you’re not looking. By the time a bug is discovered, more code has been layered on top of it – making it harder and more expensive to fix. Testing changes right away dramatically reduces the cost of addressing defects, so you should kick off a build with each commit, or at the very least on scheduled intervals throughout the day.

Working Software

Mentioned as one of the four values from the Agile Manifesto, “Working software over Comprehensive documentation” and also in several of the principles, we must recognize the importance of producing working software, within an iteration. This means that not only the software respects agreed-upon testing standards, but also has passed all the tests included in the Definition of Done for the organization. In Scrum it’s referred to as “potentially shippable product increment“, which means that if the work has been accepted then it could ship immediately, and therefore must have been thoroughly tested.

5. Daily Stand Up

The last level of planning should not be undermined. Having a clear plan every morning before starting the day is critical to ensure that the team is on the same page and that everyone on the team has a sense of purpose and meaning about the work to be accomplished each day. This planning-level takes place within a daily session lasting no more than 15 minutes, where each member of the team answers the following 3 questions:

What did I accomplish yesterday?
What I am planning to accomplish today?
Any impediments in my way?

This short planning session is typically followed by breakout sessions based on the facts shared during the Daily Stand Up. Since we don’t focus on solving issues during the Daily Stand Up, the topics that require deeper conversations or help from other team members should be tackled immediately during these breakout sessions. The best time for anyone in the organization to communicate with a team is to catch them at the end of the Daily Stand Up.

Related Blogs…