During the Build Phase, the team works in short iterations, called Sprints, where a functional increment of the application is defined, configured and validated. During each iteration, the team follows a Scrum-based process where they commit to delivering a subset of the product backlog, taking each requirement through the development lifecycle.
The goals of the Build phase are:
Duration: The build phase is typically conducted in 2 weeks iterations.
The team along with the Product Owner will plan and commit to a set of user stories which they believe can be delivered in that iteration. The Team Lead ensures that the event takes place. Sprint Planning answers what can be delivered in the Increment resulting from the upcoming Sprint and how the work needed to deliver the Increment will be achieved.
The backlog of features is prioritized by the Product Owner and estimated by the Development Team. Then the most important features which can be completed are selected. By performing this detailed planning with each iteration, the team can react to new information, pulling in newly discovered, high-priority features. Iteration planning includes these activities:
During each iteration, the team will hold refinement sessions to further detail the requirements in the remaining backlog. The Team Lead ensures this meeting takes place to make sure the backlog contains the target of “2 Sprints worth of User Stories in the backlog” at the start of the upcoming new Sprint.
The meetings are attended by the full development team, the product owner and any additional subject matter experts invited by the product owner. At this time the User Stories should already be prepared by the Product Owner to what he believes is Definition of Ready. Critical business questions are already answered between the Product Owner and the business. During the sessions the team will review, provide clarity on and break large stories into smaller ones to prepare stories for development. The team will use their predefined standard (“Definition of Ready”) to determine how much detail is needed to consider a story ready for development.
Key Insight: Use just-in-time requirements analysis to reduce wasted effort.
It is not necessary for all stories in the backlog to meet the DoR at the start of a project. Teams will work over the course of the project to add the right amount of detail at the right time. As a story rises in priority and nears the top of the backlog, more detail will be provided during backlog refinement sessions. Generally, teams should ensure enough stories meet the DoR to fill one to two iterations. This technique allows the team to avoid wasted effort on requirements that may be deprioritized as new information emerges.
During an iteration, each feature goes through the entire development cycle including design, development, testing and review by the product owner. This happens fast when using a low-code platform. With Appian’s visual modeling tools, it's possible for a single Appian developer to bring each feature to life. Testing and review of each feature happens within the iteration allowing the developer to validate that they are truly done with the feature as defined by the Definition of Done.
Each developer will follow a structured set of activities, or development workflow, to implement each story and meet the DoD. The workflow should be tailored based on the context the team is working within, but should include the following steps:
Key Insight: Embed testing into development
The majority of testing activities should be performed during the build phase as part of the development workflow for each story. It is more efficient to resolve defects during the development process and delaying testing may “hide” work to correct defects that is not accounted for in the plan. It may be necessary to delay some testing, which has a high cost to perform, to the Release phase, but this should be minimized. Teams should design their workflow to include testing which is commonly delayed such as PO acceptance and performance testing. See the Testing Guide for more details on best practice.
Development teams use a series of environments to perform their development activities, with different steps of the development workflow happening in each environment. This process is referred to as The Deployment Pipeline.
The team will agree how their pipeline will be used during the planning phase but at a minimum the pipeline should include the following environments:
Even with a well considered plan, development teams will encounter unanticipated obstacles and will need to adapt to new information. Appian teams use a set of Scrum-based meetings to routinely inspect progress and adapt as needed to achieve the team’s goal.
Each day, the team will meet to review progress toward the iteration’s goal and coordinate their activities for that day. The meeting, frequently called a stand-up, is scheduled at the same time each day for only 15 minutes. The team will decide how best to run the meeting, but it typically involves each team member answering three questions:
The most important goal of the meeting is to keep development moving forward. The team lead will capture any obstacles the team is facing and work to quickly remove them.
Key Insight: Make impediments transparent.
Quickly removing obstacles the team encounters is essential to moving fast. Teams should track impediments in a visible way to facilitate communication with the extended team and to maintain focus on their removal. One way to do this is to maintain a shared list of obstacles in an Impediment Tracker.
At the end of each Sprint, the team will demo the completed features to the larger stakeholder group. The product owner will have seen each feature as it was completed, but this is an opportunity for more users to see what progress has been made and to validate that the application will meet their needs. By reviewing progress frequently, it’s easier to course correct if needed and helps with user adoption once the application is deployed.
Standard Iteration Review Agenda:
In addition to the showcase, the team should discuss any changes to the Release Plan that are necessary given new information.
In addition to the Sprint Review, the delivery team will meet with key project stakeholders (e.g. PO, business & technical SME’s) to reflect on how to become more efficient. The team will use this Retrospective Meeting to celebrate what’s working well and identify specific actions the team may take to improve. After reviewing data from the previous iteration, the team identifies a small number of concrete actions that they can attempt with the next iteration. The goal of the meeting is to drive continuous improvement of the team’s way of working.
The next phase in Appian's Delivery Methodology is Release, where you'll learn how to leverage testing and deployment automation to ensure readiness before deployment.