Before teams begin to build, they need to be sure they're headed in the right direction. Following agile methods, much of the detailed planning and design happens incrementally as the application is built. The right amount of upfront planning ensures that the team is grounded in a deep understanding of stakeholder needs. During the Initiate phase, development teams define a plan for the application that ensures both high value and rapid delivery. With proper backlog refinement practices, a team should be able to continue building additional releases without needing to perform this phase again, although it may make sense to do so at the beginning of a major effort.
The goals of the Initiate phase are to:
Duration: The Initiate Phase is typically conducted over the course of 1-2 weeks.
We clearly define the expected business outcomes the project team must deliver and ensure all stakeholders have a common understanding of success. Business and IT collaborate to define the desired outcome based on five key discussion topics: vision, stakeholders, needs, application and business goals. We recommend to use the Application Vision Board template to guide you through this exercise in a collaborative effort (download link at the bottom of this article).
Learn more about creating an Application Vision Board here.
With the goal in mind, the team needs to define what to build to make that happen. While the team doesn’t need to detail every requirement up front, they do need to understand enough about the full scope of the solution in order to select and estimate the first release. Teams will also do enough design in order to make key design decisions and ensure they start building on a solid foundation.
Defining the application starts with understanding those who will use it. For each type of user, teams should create a persona. The persona not only defines the role this person plays in the application, but also describes a representative profile of the person, including their background, needs and typical work environment. By personalizing the user profile, teams can focus on what end users really need and how they will interact with the application.
The persona could include:
Given that the new application will change the way stakeholders work, developers need to understand that context well and look for ways to make their job easier. Ideally, this would happen by “walking the floor” with real users performing their jobs. If that’s not possible, an SME could describe it. For each major step in the process, focus on two things:
Now, development teams must identify the required functionality for the application. Teams do this using a technique called Story Mapping, where they will identify what, exactly, the application will need to do. By distilling the major activities users perform into smaller tasks, teams can show how everything fits together. Each of these requirements will be captured in a User Story which illustrates how the user will interact with the application. By focusing on the interaction and expected application behavior, this avoids constraining the team to a specific design at such an early stage. Finally, all of the stories from the map will be collected into a list of requirements, called the Product Backlog.
In addition to the required application behavior, teams must identify important non-functional requirements of the solution. These include:
Teams should also perform an environment sizing analysis at this stage in order to forecast infrastructure requirements.
For critical design elements, teams create light-weight prototypes. This allows for fast feedback from stakeholders and to ensure the team has a clear understanding of what’s needed. It’s often easier for users to communicate what they need by reacting to something concrete. Light-weight prototypes enable valuable feedback without significant effort.
Here are typically the important design aspects to prototype during the design phase:
Finally, teams must create a plan for releasing the application. The release plan shows the order in which requirements will be addressed along with an expected schedule. The plan should be high level, so that the team can adapt to new information during the project, but should clearly forecast what the team expects to deliver in the next 3-6 iterations (ie. 6-12 weeks).
The plan should deliver value to stakeholders quickly. To do this, decompose the full scope of the application into subsets that can be released incrementally, with the most valuable subsets released quickly and additional functionality delivered in frequent follow-on releases. This approach maximizes the project’s impact by getting value to the business faster and minimizes risk by allowing feedback from early releases to be corrected quickly.
Key Insight: Prioritize the backlog based on goals
Selecting the right first release relies on the Product Owner to prioritize the application’s features. However this is often a difficult task when most of the requirements of an application are all seemingly important to getting the job done. In order to make this easier, teams can use a framework called Impact Mapping. With this method, teams map each major feature to one of the project’s goals, showing the impact implementing this feature will have on the goal. This allows the Product Owner to select those features that will have the greatest impact on the project’s goals.
Because our Build process is iterative, detailed planning is done with each iteration and only locks teams into the next 2 weeks. This allows teams to adapt to new information or demand. However, we also recommend creating a Release Plan to provide stakeholders a longer term forecast. This Release Plan is a high-level, adaptable plan that forecasts what will be delivered in the next 3-6 iterations.
To create the Release Plan, we need two things: 1) the size of each backlog item represented as story points and 2) the team’s velocity, or the number of story points they can complete in an iteration. Teams estimate enough of the prioritized backlog to finalize the release plan and then communicate the plan to stakeholders.
Previous steps have discussed what is being built and when, but it is equally important to discuss how the team will work together to build it. Before getting started, teams need to make important decisions about how the extended team will work together during the project. These include:
You'll also want to include a testing strategy that includes key decisions on how acceptance testing will be conducted, how performance testing will be carried out, and how regulatory compliance will be handled.
The Definition of Ready (DoR) establishes the criteria a story must meet in order for the delivery team to start working on it (i.e. a story is ready to be brought into an iteration.) If stories are not sufficiently understood at the start of an iteration, the team can be less efficient. They may become blocked from completing the story due to details that are missing or may incorrectly estimate it causing the plan to be missed.
The Definition of Done (DoD) defines the criteria a story must meet in order for the delivery team to consider it complete. The DoD will include the required levels of testing and documentation and will ideally include all work needed for a story to be released to users. By setting this standard, the team ensures that all work for a story is done within the iteration when it is fresh in developers minds, so that there is not unplanned work when it is time to release the story.
The next phase in Appian's Delivery Methodology is Build, where you'll learn key concepts around agile planning and disciplined development. Before moving on, you'll want to ensure you are 'Build' ready and that key milestones have been met.