Software Development Lifecycle (SDLC)

1. Agile – Definition and terminology

A series of values and principles that provide a guidance for project management, respond to change,
and work as a team. It is considered a project management philosophy, not a methodology.

The frameworks or methodologies use agile principles are: Scrum, Kanban, Feature-driven development.

Appian uses a version of Scrum for its Build phase since Scrum allows developers to build and deliver
value fast.

What is Scrum?
- It is a simple and practical approach to software development.
- You will work as a team to incrementally deliver small units of work (or complete user stories)
for and application.
- The teams will be composed of:
 Product owner: is responsible for maximizing the value of the product resulting from
the development team’s work.

These are the responsibilities of this role:

 Clearly expressing what the business needs.
 Defining and prioritizing all the user stories in the product (or application)
backlog.
 Ensuring that the requirements are visible, transparent, and clear to all, and
shows what the team will work on next.
 Ensuring the team understands requirements to the level needed.

The product owner is a critical role. This person should have the following
characteristics:
 Authority to make prioritization decisions.
 Availability to work with the development team on a regular basis.
 Deep understanding of the business domain (ideally a member of the business
team).
 The product owner is one person, not a committee. The product owner may
represent the desires of a committee, but the development team needs a
single person to make fast decisions throughout the process.

 Scrum master or team lead: the team lead is the servant-leader to the development
team and coordinates the development process with the product owner so that the
team can move quickly and with minimal disruption.

This role presents following responsibilities:

 Coordinates project activities according to Appian’s Delivery Methodology.
 First point of contact to the development team for the product owner and
other stakeholders.
 Guards Appian agile best practices.

 Developers: creates applications in Appian to meet business requirements.

These are the responsibilities of this role:

 Design and implement application features using Appian’s design tools.
 Collects and refines requirements with stakeholders.
 Test features to validate requirements are met.
 Follows Appian’s Delivery Methodology.
- Increments are called sprints and typically last 2 weeks. An entire project is made up of a series
of sprints, including sprint 0. In each sprint, it will be developed and tested product backlog
items, user stories and defects.

A sprint is an event and due to this, Scrum is organized around 5 event:

 Own sprint.
 Sprint planning.
 Daily scrum.
 Sprint review.
 Sprint retrospective.

- User stories are software feature descriptions written in a non-technical, natural language. This
stories are written from the perspective of the end user. After a user story is implemented,
there is a working piece of functionality than can be tested by the end users.
1. Phases

1.1. Initiate
During this phase, frequently called “Sprint 0”, the team will define the goals of the project, explore
what the application must do to reach those goals, and map out a plan to deliver value quickly. This
is accomplished through collaborative sessions with stakeholders from across business and IT. This
ensures every point of view is included and stakeholders are aligned around a common goal. The
intent is not to define every project detail, but rather to perform enough planning and design to get
started in the right direction. As a result, teams usually complete these activities in one to two
weeks.

The main goals of this phase are:

1) Define success: Ensure a shared understanding of success across all stakeholders. Business
and IT collaborate to define the desired outcome based on five key discussion topics:
 Vision: A statement or slogan that captures the application’s purpose. What is the
essence of what we will achieve by implementing the product? It can be something
straightforward like “Quickly and easily onboard new hires to our company”.

 Stakeholders: which people should benefit most from the product? Who are the
product’s users, customers and wider stakeholders who will feel the (bottom-line)
benefit from the outcome (e.g. the sponsor or line manager of the end users). For an
internal recruitment and hiring application this can be HR Officials, Recruitment
Agents, Legal, Line Managers and the new hires themselves.

 Needs: “What problem are we trying to solve?” Identify pain points and bottlenecks
in the current way of working; functional and technical. You can also ask: “what are
the benefits the solution should provide?”. Possible responses can be:
o Increase transparency of the process so we can easily see where and with
whom a request is currently sitting.
o Give new employees a smooth and pleasant first exposure to internal
operations.
o Ensure a quick and easy handover between task owners without delays and
lost emails.

 Application: We define the high level features or characteristics that will drive the
product value. For example: the product needs to be web-based and accessible via
 mobile devices, or tasks need to be automatically created and assigned to task
owners.
The output helps the development team visualize the application and set
expectations to project and product capability.

 Business goals: What are the measurable business goals in order of priority? These
goals typically relate to a business’ Key Performance Indicators (KPIs). Examples of
these are: reducing new hire boarding lead time from 5 days to less than 1 day, or
reduce the time spent on boarding by all users in the process by 60%.

The business goals provide the ultimate benchmark to measure the need and priority
of a business requirement. They are also key input for defining and prioritizing the
application’s report requirements.

KPIs serve multiple purposes. Establishing measures for the business goals of a
project allows to calculate the project’s return on investment, and can be used as a
way to clarify the expected outcome to the entire project team. Also, you can use it
to assist with difficult prioritization decisions by asking how a feature contributes to
the overall objective.

The responsibility of creating this item is up to the Product Owner and more senior members
of the team.

2) Explore scope: establish a backlog of requirements and ensure there’s enough detail to get
started. The backlog is made up of all users stories for the application.

Step 1: Define Personas

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:

 Name and role.
 Technology familiarity.
 Devices used.
 What activities they perform in a typical day.
 Current pain points.

Step 2: Review Current State

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:

1. Why do they perform each activity (ie. What outcome are they trying to create)?
2. What are their biggest pain points (ie. What makes this activity hard today)?

Step 3: Build the Product Backlog

 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.

Step 4: Identify Design Constraints

In addition to the required application behavior, teams must identify important non-
functional requirements of the solution. These include:

1. The expected usage including total number of users and expected peak concurrent
usage.
2. Expected user interface response thresholds.
3. Expected annual record counts for key entities.
4. Security requirements.
5. Accessibility requirements.

Teams should also perform an environment sizing analysis at this stage in order to
forecast infrastructure requirements.

Step 5: Prototype Ideas

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:
1. A conceptual model of business objects and their relationships to each other.
2. User and Role management.
3. The screen flow of major use cases.
4. Expected reporting needs.
5. Integration points with external systems.
6. Document management strategy.

The responsibility of creating this item is up to the Product Owner and more senior members
of the team.

3) Plan releases: define an incremental release plan and estimate the time for the first release.
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).

Step 1: Devise an incremental release strategy

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.

Step 2: Create the Release Plan

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.

4) Agree on a Way of Working: schedule regular meetings and team processes. Before getting
started, teams need to make important decisions about how the extended team will work
together during the project. These include:

1. Scheduling the key ceremonies on a fixed cadence including: daily scrum, sprint planning,
spring review, backlog refinement, and sprint retrospective.
2. Design the development workflow and configure the project management tool (e.g. Jira).
3. Define the deployment pipeline and configuration management process.
4. Agree the Definition of Done (DoD) and Definition of Ready (DoR).
5. Testing strategy including these key decisions:
a. How will user acceptance testing be performed?
b. How will performance testing be performed?
c. How will regulatory compliance testing be performed?

Definition of Ready
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.

Definition of Done
 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.

Key Deliverables: The typically key deliverables in order of importance include:

 Product Backlog (stories with acceptance criteria).
 Release Plan.
 Sprint 1 Plan.
 Charter.

Quiz:
1.2. Build
The team builds the application in rapid iterations, usually two weeks in length, where a subset of
features go through the full development cycle, with development and business quality-checks built
into each iteration. The build process facilitates continuous collaboration between the development
team and stakeholders. This phase can be further split into three disciplines:

1) Agile Planning. Use just-in-time requirement discovery and iterative planning cycles in order
to adapt the release plan to new information.

a) Backlog Refinement: 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.

b) Story Sizing: Consists of three steps:

 Select and discuss a story. This is time to ask questions make sure there are no missing
requirements, and look at dependencies between this story and others. You should also
determine if you want to split the user story into multiple stories.

 Individually estimate points for the story. Story points are used to estimate the effort
required to fully implement a user story. An easy to implement user story may receive a
one, while a very challenging story may receive a thirteen. We’re going to use the first
six numbers in the Fibonacci sequence: one, two, three, five, eight, and thirteen. And 8
is anything you’d point 6-8, and a 13 is 9 to 13.

It is important to designate a ceiling. Most teams use 13 as a high point. Anything

pointed above that is split into multiple stories.

 Discuss the estimate and assign points. If you reach a quick consensus, move on the
next story. If you can’t reach a quick consensus then the individuals with the highest
and lowest points should share their rationale.

c) Sprint Planning: 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:

1. Prioritize – The product owner orders the backlog in order of priority.

2. Estimate – The team estimates each backlog item in story points. An easy to
implement user story may receive a one, while a very challenging story may receive a
thirteen. We’re going to use the first six numbers in the Fibonacci sequence: one, two,
three, five, eight, and thirteen. And 8 is anything you’d point 6-8, and a 13 is 9 to 13.

It is important to designate a ceiling. Most teams use 13 as a high point. Anything

pointed above that is split into multiple stories.
3. 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.

Quiz:
2) Disciplined development: Follow a test driven development process with quality built-in.
During an iteration, each feature goes through the entire development cycle including design,
development, testing and review by the product owner. 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:

1. Create a test plan and detailed design.

2. Decompose story into tasks. There are two key things you should think about:
 Security – think about who needs permissions to see the data and/or take action on
the data. Write down the permission levels in a task.
 Time – each subtask should take 1 – 2 days to complete.
3. Create the Appian objects that deliver the required functionality. Remember PPT
(performance, best practices and testing):
 Performance: use the performance monitors to check the status of your design
objects.
  Best practices: you should follow these to ensure your application is scalable and
flexible.
 Testing: where possible, create test cases for your design objects.
4. Test the story according to the test plan.
5. Another team member peer reviews the story.
6. The product owner performs an acceptance test of the feature checking the Definition
of Done to make sure feature meets all the criteria.

Deployment Pipeline
Development teams use a series of environments, called the deployment pipeline, to
perform their development activities, with different steps of the development workflow
happening in each environment. 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:

o Development – all development activity and story-level testing are performed in this
environment.
o 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.
o Staging (optional) – this environment is to be used to test the deployments to
production and to execute performance testing, and more specifically load testing.
o 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.

Quiz:
3) Inspect and adapt. Ensure frequent communication amongst the team, making progress
transparent and continuously removing impediments.

Daily Stand-up
Each day, the team meets to discuss progress and coordinate their activities of the day. The
meeting is scheduled at the same time each day for only 15 minutes, and 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.

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:

1. Overview of features in this iteration.
2. Reminder of overall story map and where these features fit in.
3. Demo of each feature, showing how a user would interact with it.
4. 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
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.

Quiz:
1.3. Release
Before the team releases the application, they will ensure the application is technically sound and
that our stakeholders are ready to accept it. Because most testing happens during the Build phase,
little may need to be performed now, but some teams may require additional “hardening” activities
at this step. By leveraging testing and deployment automation, and by keeping releases small, teams
can perform this phase in hours rather than days.

Step 1: Ensure Technical Readiness

Most testing should occur in the Build phase, but depending on the environment you are working
in, additional testing may need to happen once an application is ready for release. The first step is
to verify that the application is functional, meets stakeholder needs, and able to handle expected
usage volumes. Ensure the following testing is complete:

1. Perform end-to-end functional testing.

2. Ensure stakeholder satisfaction.
3. Validate data migration procedures.
4. Develop and test your deployment plan.
5. Perform concurrent load testing.
6. Provision Users.

Step 2: Prepare the Business for Change

Although the application may be technically fit, it will only deliver value if our users are able to
use it. Below are important strategies to ensure the stakeholder community is prepared to adopt
the new application:

1. Identify all the stakeholders that may be affected.

2. Communicate the change.
3. Prepare the support team.
4. Educate and train end users.

Step 3: Determine Your Release Strategy

An incremental roll out strategy is one of the most effective ways to manage risk as you deploy
new functionality. Consider these common options when formulating your release strategy:

1. Pilot release.
 2. Read-only release.
3. Parallel run.

Step 4: Release Application

With the application technically ready to release, stakeholders prepared to receive it and plan in
place, it’s time to release the application and deliver value.

1.4. Optimize
Congratulations! Your application is released and is delivering value for end users. However, don’t
leave off these critical next components that will accelerate your ability to deliver even more value
to your organization, faster.

The goals of the optimize phase are:

 Sustain & Enhance: Successfully launched applications won’t stay successful for long without a
well thought-out strategy for support and continued improvement. Support strategies depend
on clear delineation and accountability and the use of effective monitoring tools like the Appian
Health Check to reduce the likelihood of application incidents before they arise.

1. Enable effective application support.

2. Use health check regularly.
3. Collect feedback for continuous improvement.

 Measure impact & communicate success: Business value measures, defined and documented
during the Initiate phase, aren’t just defined in order to ‘justify’ the budget for a new product.
They should be living concepts that are revisited and validated throughout the development
lifecycle and, as noted in the Build stage, used to prioritize the development backlog and make
mid-course tradeoffs and corrections.

Once the application is launched, it’s time to revisit these measures to use them as a foundation
for capturing the actual business value delivered by your new application. Remember, most
Appian applications deliver value through inflecting one or more of the following business value
categories.

o Reducing costs.
o Reducing risks.
o Improving customer experience.
o Enabling new products or services.

Each one of these can be quantified as a business value measurement. Once you’ve identified
the core value measures for your application, and your Application is now launched, it’s time to
measure the benefits actually achieved.