The Appian Delivery Methodology Part II

Appian Max Team — Tue, 23 Apr 2024 13:48:25 GMT

Current Revision posted to Guide by Appian Max Team on 4/23/2024 1:48:25 PM

Part I: Initiate Part II: Build Part III: Release Part IV: Optimize

Build

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:

Agile Planning - use just-in-time requirement discovery and iterative planning cycles in order to adapt the release plan to new information.
Disciplined Development - follow a test driven development process with quality built-in.
Inspect and Adapt - ensure frequent communication amongst the team, making progress transparent and continuously removing impediments.

Duration: The build phase is typically conducted in 2 weeks iterations.

Agile Planning

Step 1: Plan Sprint

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:

Prioritize - The product owner orders the backlog in order of priority.
Estimate - The team estimates each backlog item in story points following the Scrum estimation process.
Using the team’s current velocity (average of the story points completed per iteration) a set of backlog items are selected for the current iteration.

Step 2: Refine Backlog

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.

Disciplined Development

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.

Development Workflow

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:

Create a test plan and detailed design.
Break story into tasks.
Using the Appian design tools, create the Appian objects that deliver the required functionality.
Test the story according to the test plan.
Have another team member peer review the story.
Have the Product Owner perform an acceptance test of the feature.

💡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.

Deployment Pipeline

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:

Development - all development activities and story-level testing are performed in this environment.
Test - each story or change is tested on one or more test environments according to the team’s test strategy which should include functional tests, integration tests, user acceptance tests, and non functional tests such as performance tests.
Staging (optional) - this environment is to be used to test the deployments to production and to execute performance testing, and more specifically load testing.
Production - at the end of the pipeline, the changes are deployed to the production environment after tests are successful and changes are approved for release to stakeholders.

Inspect and Adapt

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.

Daily Stand-up

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:

What did I accomplish yesterday?
What will I accomplish today?
What might block me from achieving my daily goal?

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.

Sprint Review

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:

Overview of features in this iteration
Reminder of the overall story map and where these features fit in
Demo of each feature, showing how a user would interact with it
Record group feedback and adjust the backlog if needed

In addition to the showcase, the team should discuss any changes to the Release Plan that are necessary given new information.

Retrospective Meeting

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.

Up Next

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.

Previous: Initiate

Next: Release

The Appian Delivery Methodology Part II

joel.larin — Tue, 20 Feb 2024 15:35:24 GMT

Revision 9 posted to Guide by joel.larin on 2/20/2024 3:35:24 PM

Part I: Initiate Part II: Build Part III: Release Part IV: Optimize

Build

The goals of the Build phase are:

Agile Planning - use just-in-time requirement discovery and iterative planning cycles in order to adapt the release plan to new information.
Disciplined Development - follow a test driven development process with quality built-in.
Inspect and Adapt - ensure frequent communication amongst the team, making progress transparent and continuously removing impediments.

Duration: The build phase is typically conducted in 2 weeks iterations.

Agile Planning

Step 1: Plan Sprint

Prioritize - The product owner orders the backlog in order of priority.
Estimate - The team estimates each backlog item in story points following the Scrum estimation process.
Using the team’s current velocity (average of the story points completed per iteration) a set of backlog items are selected for the current iteration.

Step 2: Refine Backlog

💡Key Insight: Use just-in-time requirements analysis to reduce wasted effort.

Disciplined Development

Development Workflow

Create a test plan and detailed design.
Break story into tasks.
Using the Appian design tools, create the Appian objects that deliver the required functionality.
Test the story according to the test plan.
Have another team member peer review the story.
Have the Product Owner perform an acceptance test of the feature.

💡Key Insight: Embed testing into development

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:

Development - all development activities and story-level testing are performed in this environment.
Test - each story or change is tested on one or more test environments according to the team’s test strategy which should include functional tests, integration tests, user acceptance tests, and non functional tests such as performance tests.
Staging (optional) - this environment is to be used to test the deployments to production and to execute performance testing, and more specifically load testing.
Production - at the end of the pipeline, the changes are deployed to the production environment after tests are successful and changes are approved for release to stakeholders.

Inspect and Adapt

Daily Stand-up

What did I accomplish yesterday?
What will I accomplish today?
What might block me from achieving my daily goal?

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.

Sprint Review

Standard Iteration Review Agenda:

Overview of features in this iteration
Reminder of the overall story map and where these features fit in
Demo of each feature, showing how a user would interact with it
Record group feedback and adjust the backlog if needed

In addition to the showcase, the team should discuss any changes to the Release Plan that are necessary given new information.

Retrospective Meeting

Up Next

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.

Previous: Initiate

Next: Release

The Appian Delivery Methodology Part II

joel.larin — Tue, 20 Feb 2024 15:33:09 GMT

Revision 8 posted to Guide by joel.larin on 2/20/2024 3:33:09 PM

Part I: Initiate Part II: Build Part III: Release Part IV: Optimize

Build

The goals of the Build phase are:

Agile Planning - use just-in-time requirement discovery and iterative planning cycles in order to adapt the release plan to new information.
Disciplined Development - follow a test driven development process with quality built-in.
Inspect and Adapt - ensure frequent communication amongst the team, making progress transparent and continuously removing impediments.

Duration: The build phase is typically conducted in 2 weeks iterations.

Agile Planning

Step 1: Plan Sprint

Prioritize - The product owner orders the backlog in order of priority.
Estimate - The team estimates each backlog item in story points following the Scrum estimation process.
Using the team’s current velocity (average of the story points completed per iteration) a set of backlog items are selected for the current iteration.

Step 2: Refine Backlog

💡Key Insight: Use just-in-time requirements analysis to reduce wasted effort.

Disciplined Development

Development Workflow

Create a test plan and detailed design.
Break story into tasks.
Using the Appian design tools, create the Appian objects that deliver the required functionality.
Test the story according to the test plan.
Have another team member peer review the story.
Have the Product Owner perform an acceptance test of the feature.

💡Key Insight: Embed testing into development

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:

Development - all development activities and story-level testing are performed in this environment.
Test - each story or change is tested on one or more test environments according to the team’s test strategy which should include functional tests, integration tests, user acceptance tests, and non functional tests such as performance tests.
Staging (optional) - this environment is to be used to test the deployments to production and to execute performance testing, and more specifically load testing.
Production - at the end of the pipeline, the changes are deployed to the production environment after tests are successful and changes are approved for release to stakeholders.

Inspect and Adapt

Daily Stand-up

Development - all development activities and story-level testing are performed in this environment.
Test - each story or change is tested on one or more test environments according to the team’s test strategy which should include functional tests, integration tests, user acceptance tests, and non functional tests such as performance tests.
Staging (optional) - this environment is to be used to test the deployments to production and to execute performance testing, and more specifically load testing.
Production - at the end of the pipeline, the changes are deployed to the production environment after tests are successful and changes are approved for release to stakeholders.

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.

Sprint Review

Standard Iteration Review Agenda:

Overview of features in this iteration
Reminder of the overall story map and where these features fit in
Demo of each feature, showing how a user would interact with it
Record group feedback and adjust the backlog if needed

In addition to the showcase, the team should discuss any changes to the Release Plan that are necessary given new information.

Retrospective Meeting

Up Next

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.

Previous: Initiate

Next: Release

The Appian Delivery Methodology Part II

joel.larin — Wed, 02 Aug 2023 17:08:25 GMT

Revision 7 posted to Guide by joel.larin on 8/2/2023 5:08:25 PM

Part I: Initiate Part II: Build Part III: Release Part IV: Optimize

Build

The goals of the Build phase are:

Agile Planning - use just-in-time requirement discovery and iterative planning cycles in order to adapt the release plan to new information.
Disciplined Development - follow a test driven development process with quality built-in.
Inspect and Adapt - ensure frequent communication amongst the team, making progress transparent and continuously removing impediments.

Duration: The build phase is typically conducted in 2 weeks iterations.

Agile Planning

Step 1: Plan Sprint

Prioritize - The product owner orders the backlog in order of priority.
Estimate - The team estimates each backlog item in story points following the Scrum estimation process.
Using the team’s current velocity (average of the story points completed per iteration) a set of backlog items are selected for the current iteration.

Step 2: Refine Backlog

💡Key Insight: Use just-in-time requirements analysis to reduce wasted effort.

Disciplined Development

Development Workflow

Prioritize - The product owner orders the backlog in order of priority.
Estimate - The team estimates each backlog item in story points following the Scrum estimation process.
Using the team’s current velocity (average of the story points completed per iteration) a set of backlog items are selected for the current iteration.

💡Key Insight: Embed testing into development

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:

Development - all development activities and story-level testing are performed in this environment.
Test - each story or change is tested on one or more test environments according to the team’s test strategy which should include functional tests, integration tests, user acceptance tests, and non functional tests such as performance tests.
Staging (optional) - this environment is to be used to test the deployments to production and to execute performance testing, and more specifically load testing.
Production - at the end of the pipeline, the changes are deployed to the production environment after tests are successful and changes are approved for release to stakeholders.

Inspect and Adapt

Daily Stand-up

Development - all development activities and story-level testing are performed in this environment.
Test - each story or change is tested on one or more test environments according to the team’s test strategy which should include functional tests, integration tests, user acceptance tests, and non functional tests such as performance tests.
Staging (optional) - this environment is to be used to test the deployments to production and to execute performance testing, and more specifically load testing.
Production - at the end of the pipeline, the changes are deployed to the production environment after tests are successful and changes are approved for release to stakeholders.

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.

Sprint Review

Standard Iteration Review Agenda:

Overview of features in this iteration
Reminder of the overall story map and where these features fit in
Demo of each feature, showing how a user would interact with it
Record group feedback and adjust the backlog if needed

In addition to the showcase, the team should discuss any changes to the Release Plan that are necessary given new information.

Retrospective Meeting

Up Next

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.

Previous: Initiate

Next: Release

The Appian Delivery Methodology Part II

Devon Lee — Wed, 22 Mar 2023 18:07:28 GMT

Revision 6 posted to Guide by Devon Lee on 3/22/2023 6:07:28 PM

Build

Part I: Initiate Part II: Build Part III: Release Part IV: Optimize

The goals of the Build phase are:

Agile Planning - use just-in-time requirement discovery and iterative planning cycles in order to adapt the release plan to new information.
Disciplined Development - follow a test driven development process with quality built-in.
Inspect and Adapt - ensure frequent communication amongst the team, making progress transparent and continuously removing impediments.

Duration: The build phase is typically conducted in 2 weeks iterations.

Agile Planning

Step 1: Plan Sprint

Prioritize - The product owner orders the backlog in order of priority.
Estimate - The team estimates each backlog item in story points following the Scrum estimation process.
Using the team’s current velocity (average of the story points completed per iteration) a set of backlog items are selected for the current iteration.

Step 2: Refine Backlog

💡Key Insight: Use just-in-time requirements analysis to reduce wasted effort.

Disciplined Development

Development Workflow

Prioritize - The product owner orders the backlog in order of priority.
Estimate - The team estimates each backlog item in story points following the Scrum estimation process.
Using the team’s current velocity (average of the story points completed per iteration) a set of backlog items are selected for the current iteration.

💡Key Insight: Embed testing into development

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:

Development - all development activities and story-level testing are performed in this environment.
Test - each story or change is tested on one or more test environments according to the team’s test strategy which should include functional tests, integration tests, user acceptance tests, and non functional tests such as performance tests.
Staging (optional) - this environment is to be used to test the deployments to production and to execute performance testing, and more specifically load testing.
Production - at the end of the pipeline, the changes are deployed to the production environment after tests are successful and changes are approved for release to stakeholders.

Inspect and Adapt

Daily Stand-up

Development - all development activities and story-level testing are performed in this environment.
Test - each story or change is tested on one or more test environments according to the team’s test strategy which should include functional tests, integration tests, user acceptance tests, and non functional tests such as performance tests.
Staging (optional) - this environment is to be used to test the deployments to production and to execute performance testing, and more specifically load testing.
Production - at the end of the pipeline, the changes are deployed to the production environment after tests are successful and changes are approved for release to stakeholders.

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.

Sprint Review

Standard Iteration Review Agenda:

Overview of features in this iteration
Reminder of the overall story map and where these features fit in
Demo of each feature, showing how a user would interact with it
Record group feedback and adjust the backlog if needed

In addition to the showcase, the team should discuss any changes to the Release Plan that are necessary given new information.

Retrospective Meeting

Up Next

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.

Previous: Initiate

Next: Release

The Appian Delivery Methodology Part II

joel.larin — Mon, 12 Dec 2022 20:24:29 GMT

Revision 5 posted to Guide by joel.larin on 12/12/2022 8:24:29 PM

Build

Part I: Initiate Part II: Build Part III: Release Part IV: Optimize

The goals of the Build phase are:

Agile Planning - use just-in-time requirement discovery and iterative planning cycles in order to adapt the release plan to new information.
Disciplined Development - follow a test driven development process with quality built-in.
Inspect and Adapt - ensure frequent communication amongst the team, making progress transparent and continuously removing impediments.

Duration: The build phase is typically conducted in 2 weeks iterations.

Agile Planning

Step 1: Plan Sprint

Prioritize - The product owner orders the backlog in order of priority.
Estimate - The team estimates each backlog item in story points following the Scrum estimation process.
Using the team’s current velocity (average of the story points completed per iteration) a set of backlog items are selected for the current iteration.

Step 2: Refine Backlog

💡Key Insight: Use just-in-time requirements analysis to reduce wasted effort.

Disciplined Development

Development Workflow

Prioritize - The product owner orders the backlog in order of priority.
Estimate - The team estimates each backlog item in story points following the Scrum estimation process.
Using the team’s current velocity (average of the story points completed per iteration) a set of backlog items are selected for the current iteration.

💡Key Insight: Embed testing into development

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:

Development - all development activities and story-level testing are performed in this environment.
Test - each story or change is tested on one or more test environments according to the team’s test strategy which should include functional tests, integration tests, user acceptance tests, and non functional tests such as performance tests.
Staging (optional) - this environment is to be used to test the deployments to production and to execute performance testing, and more specifically load testing.
Production - at the end of the pipeline, the changes are deployed to the production environment after tests are successful and changes are approved for release to stakeholders.

Inspect and Adapt

Daily Stand-up

Development - all development activities and story-level testing are performed in this environment.
Test - each story or change is tested on one or more test environments according to the team’s test strategy which should include functional tests, integration tests, user acceptance tests, and non functional tests such as performance tests.
Staging (optional) - this environment is to be used to test the deployments to production and to execute performance testing, and more specifically load testing.
Production - at the end of the pipeline, the changes are deployed to the production environment after tests are successful and changes are approved for release to stakeholders.

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.

Sprint Review

Standard Iteration Review Agenda:

Overview of features in this iteration
Reminder of the overall story map and where these features fit in
Demo of each feature, showing how a user would interact with it
Record group feedback and adjust the backlog if needed

In addition to the showcase, the team should discuss any changes to the Release Plan that are necessary given new information.

Retrospective Meeting

Up Next

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.

Previous: Initiate

Next: Release

The Appian Delivery Methodology Part II

joel.larin — Mon, 12 Dec 2022 02:47:47 GMT

Revision 4 posted to Guide by joel.larin on 12/12/2022 2:47:47 AM

Build

Part I: Initiate Part II: Build Part III: Release Part IV: Optimize

The goals of the Build phase are:

Agile Planning - use just-in-time requirement discovery and iterative planning cycles in order to adapt the release plan to new information.
Disciplined Development - follow a test driven development process with quality built-in.
Inspect and Adapt - ensure frequent communication amongst the team, making progress transparent and continuously removing impediments.

Duration: The build phase is typically conducted in 2 weeks iterations.

Agile Planning

Step 1: Plan Sprint

Prioritize - The product owner orders the backlog in order of priority.
Estimate - The team estimates each backlog item in story points following the Scrum estimation process.
Using the team’s current velocity (average of the story points completed per iteration) a set of backlog items are selected for the current iteration.

Step 2: Refine Backlog

💡Key Insight: Use just-in-time requirements analysis to reduce wasted effort.

Disciplined Development

Development Workflow

Prioritize - The product owner orders the backlog in order of priority.
Estimate - The team estimates each backlog item in story points following the Scrum estimation process.
Using the team’s current velocity (average of the story points completed per iteration) a set of backlog items are selected for the current iteration.

💡Key Insight: Embed testing into development

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:

Development - all development activities and story-level testing are performed in this environment.
Test - each story or change is tested on one or more test environments according to the team’s test strategy which should include functional tests, integration tests, user acceptance tests, and non functional tests such as performance tests.
Staging (optional) - this environment is to be used to test the deployments to production and to execute performance testing, and more specifically load testing.
Production - at the end of the pipeline, the changes are deployed to the production environment after tests are successful and changes are approved for release to stakeholders.

Inspect and Adapt

Daily Stand-up

Development - all development activities and story-level testing are performed in this environment.
Test - each story or change is tested on one or more test environments according to the team’s test strategy which should include functional tests, integration tests, user acceptance tests, and non functional tests such as performance tests.
Staging (optional) - this environment is to be used to test the deployments to production and to execute performance testing, and more specifically load testing.
Production - at the end of the pipeline, the changes are deployed to the production environment after tests are successful and changes are approved for release to stakeholders.

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.

Sprint Review

Standard Iteration Review Agenda:

Overview of features in this iteration
Reminder of the overall story map and where these features fit in
Demo of each feature, showing how a user would interact with it
Record group feedback and adjust the backlog if needed

In addition to the showcase, the team should discuss any changes to the Release Plan that are necessary given new information.

Retrospective Meeting

Up Next

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.

Previous: Initiate

Next: Release

Tags: Delivery

The Appian Delivery Methodology Part II

joel.larin — Mon, 12 Dec 2022 02:32:54 GMT

Revision 3 posted to Guide by joel.larin on 12/12/2022 2:32:54 AM

Build

Part I: Initiate Part II: Build Part III: Release Part IV: Optimize

The goals of the Build phase are:

Agile Planning - use just-in-time requirement discovery and iterative planning cycles in order to adapt the release plan to new information.
Disciplined Development - follow a test driven development process with quality built-in.
Inspect and Adapt - ensure frequent communication amongst the team, making progress transparent and continuously removing impediments.

Duration: The build phase is typically conducted in 2 weeks iterations.

Agile Planning

Step 1: Plan Sprint

Prioritize - The product owner orders the backlog in order of priority.
Estimate - The team estimates each backlog item in story points following the Scrum estimation process.
Using the team’s current velocity (average of the story points completed per iteration) a set of backlog items are selected for the current iteration.

Step 2: Refine Backlog

💡Key Insight: Use just-in-time requirements analysis to reduce wasted effort.

Disciplined Development

Development Workflow

Prioritize - The product owner orders the backlog in order of priority.
Estimate - The team estimates each backlog item in story points following the Scrum estimation process.
Using the team’s current velocity (average of the story points completed per iteration) a set of backlog items are selected for the current iteration.

💡Key Insight: Embed testing into development

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:

Development - all development activities and story-level testing are performed in this environment.
Test - each story or change is tested on one or more test environments according to the team’s test strategy which should include functional tests, integration tests, user acceptance tests, and non functional tests such as performance tests.
Staging (optional) - this environment is to be used to test the deployments to production and to execute performance testing, and more specifically load testing.
Production - at the end of the pipeline, the changes are deployed to the production environment after tests are successful and changes are approved for release to stakeholders.

Inspect and Adapt

Daily Stand-up

Development - all development activities and story-level testing are performed in this environment.
Test - each story or change is tested on one or more test environments according to the team’s test strategy which should include functional tests, integration tests, user acceptance tests, and non functional tests such as performance tests.
Staging (optional) - this environment is to be used to test the deployments to production and to execute performance testing, and more specifically load testing.
Production - at the end of the pipeline, the changes are deployed to the production environment after tests are successful and changes are approved for release to stakeholders.

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.

Sprint Review

Standard Iteration Review Agenda:

Overview of features in this iteration
Reminder of the overall story map and where these features fit in
Demo of each feature, showing how a user would interact with it
Record group feedback and adjust the backlog if needed

In addition to the showcase, the team should discuss any changes to the Release Plan that are necessary given new information.

Retrospective Meeting

Up Next

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.

Previous: Initiate

Next: Release

Tags: Delivery

The Appian Delivery Methodology Part II

joel.larin — Mon, 12 Dec 2022 02:30:19 GMT

Revision 2 posted to Guide by joel.larin on 12/12/2022 2:30:19 AM

Build

Part I: Initiate Part II: Build Part III: Release Part IV: Optimize

The goals of the Build phase are:

Agile Planning - use just-in-time requirement discovery and iterative planning cycles in order to adapt the release plan to new information.
Disciplined Development - follow a test driven development process with quality built-in.
Inspect and Adapt - ensure frequent communication amongst the team, making progress transparent and continuously removing impediments.

Duration: The build phase is typically conducted in 2 weeks iterations.

Agile Planning

Step 1: Plan Sprint

Prioritize - The product owner orders the backlog in order of priority.
Estimate - The team estimates each backlog item in story points following the Scrum estimation process.
Using the team’s current velocity (average of the story points completed per iteration) a set of backlog items are selected for the current iteration.

Step 2: Refine Backlog

💡Key Insight: Use just-in-time requirements analysis to reduce wasted effort.

Disciplined Development

Development Workflow

Prioritize - The product owner orders the backlog in order of priority.
Estimate - The team estimates each backlog item in story points following the Scrum estimation process.
Using the team’s current velocity (average of the story points completed per iteration) a set of backlog items are selected for the current iteration.

💡Key Insight: Embed testing into development

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:

Development - all development activities and story-level testing are performed in this environment.
Test - each story or change is tested on one or more test environments according to the team’s test strategy which should include functional tests, integration tests, user acceptance tests, and non functional tests such as performance tests.
Staging (optional) - this environment is to be used to test the deployments to production and to execute performance testing, and more specifically load testing.
Production - at the end of the pipeline, the changes are deployed to the production environment after tests are successful and changes are approved for release to stakeholders.

Inspect and Adapt

Daily Stand-up

Development - all development activities and story-level testing are performed in this environment.
Test - each story or change is tested on one or more test environments according to the team’s test strategy which should include functional tests, integration tests, user acceptance tests, and non functional tests such as performance tests.
Staging (optional) - this environment is to be used to test the deployments to production and to execute performance testing, and more specifically load testing.
Production - at the end of the pipeline, the changes are deployed to the production environment after tests are successful and changes are approved for release to stakeholders.

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.

Sprint Review

Standard Iteration Review Agenda:

Overview of features in this iteration
Reminder of the overall story map and where these features fit in
Demo of each feature, showing how a user would interact with it
Record group feedback and adjust the backlog if needed

In addition to the showcase, the team should discuss any changes to the Release Plan that are necessary given new information.

Retrospective Meeting

Up Next

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.

Previous: Initiate

Next: Release

Tags: Delivery

The Appian Delivery Methodology Part II

joel.larin — Fri, 09 Dec 2022 16:50:56 GMT

Revision 1 posted to Guide by joel.larin on 12/9/2022 4:50:56 PM

Build

Part I: Initiate Part II: Build Part III: Release Part IV: Optimize

The goals of the Build phase are:

Agile Planning - use just-in-time requirement discovery and iterative planning cycles in order to adapt the release plan to new information.
Disciplined Development - follow a test driven development process with quality built-in.
Inspect and Adapt - ensure frequent communication amongst the team, making progress transparent and continuously removing impediments.

Duration: The build phase is typically conducted in 2 weeks iterations.

Agile Planning

Step 1: Plan Sprint

Prioritize - The product owner orders the backlog in order of priority.
Estimate - The team estimates each backlog item in story points following the Scrum estimation process.
Using the team’s current velocity (average of the story points completed per iteration) a set of backlog items are selected for the current iteration.

Step 2: Refine Backlog

💡Key Insight: Use just-in-time requirements analysis to reduce wasted effort.

Disciplined Development

Development Workflow

Prioritize - The product owner orders the backlog in order of priority.
Estimate - The team estimates each backlog item in story points following the Scrum estimation process.
Using the team’s current velocity (average of the story points completed per iteration) a set of backlog items are selected for the current iteration.

💡Key Insight: Embed testing into development

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:

Development - all development activities and story-level testing are performed in this environment.
Test - each story or change is tested on one or more test environments according to the team’s test strategy which should include functional tests, integration tests, user acceptance tests, and non functional tests such as performance tests.
Staging (optional) - this environment is to be used to test the deployments to production and to execute performance testing, and more specifically load testing.
Production - at the end of the pipeline, the changes are deployed to the production environment after tests are successful and changes are approved for release to stakeholders.

Inspect and Adapt

Daily Stand-up

Development - all development activities and story-level testing are performed in this environment.
Test - each story or change is tested on one or more test environments according to the team’s test strategy which should include functional tests, integration tests, user acceptance tests, and non functional tests such as performance tests.
Staging (optional) - this environment is to be used to test the deployments to production and to execute performance testing, and more specifically load testing.
Production - at the end of the pipeline, the changes are deployed to the production environment after tests are successful and changes are approved for release to stakeholders.

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.

Sprint Review

Standard Iteration Review Agenda:

Overview of features in this iteration
Reminder of the overall story map and where these features fit in
Demo of each feature, showing how a user would interact with it
Record group feedback and adjust the backlog if needed

In addition to the showcase, the team should discuss any changes to the Release Plan that are necessary given new information.

Retrospective Meeting

Up Next

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.

Previous: Initiate

Next: Release

Tags: Delivery