The Eight Stages of an

Agile Approach That Works

An Overview of the OutSystems Approach to Agile
Introduction
With the experiences gathered through 500+ Agile projects, the OutSystems team has developed and refined a
repeatable way to enable the efficient and successful delivery of enterprise-scale Agile projects. In essence, defining
an Agile method that works. This approach includes the concepts applied, the tools used and the activities conducted
for successfully delivering web business applications. By leveraging the Agile Platform and Agile Network,
organizations are able to adopt Agile development methods and scale their Agile projects across their IT organization.
At OutSystems, we believe that being Agile requires not only a set of adaptive processes but also tools that make
everyone involved with the project, agile. This includes the complete Agile delivery team------management,
development team members, business users and all key stakeholders.

Eight Stages of an OutSystems Agile Project

The OutSystems approach to Agile is comprised of the following stages as depicted by the graphic below:

1.
2.
3.
4.
5.
6.
7.
8.

Budgeting
Project Initiation
Iterative Development--- Sprint Planning, Development & Testing and Product Demo
Training
Production Launch
Tuning
Wrap-up
Maintenance

Let's take a closer look at each of these stages.

2001-2012 OutSystems ---- All rights reserved

Page 1 of 4

www.outsystems.com

1. Budgeting

What are the most critical business user profiles?

What are the most frequent user stories or use cases
that involve those profiles?

The major concepts applied during the budgeting stage are

--- User Stories, Sizing and the Project Timebox. We gather
user stories to define the project scope. User Stories are
high-level requirements defined in business terms. These
descriptions of what the Business Manager wants the
application to do are collected in days versus the more
traditional requirements gathering processes that can take
weeks or even months. Each user story is decomposed into
a set of high-level features, which are then sized to
determine the effort required to deliver them.

What are the use cases and user profiles that contribute
most to the applications ROI?
The result is a project backlog that is a prioritized list of
requirements.

The effort or size of each feature is based on its planned

pattern of implementation; for example, listing, sorting,
searching, editing, etc. Once all features are sized, the
project timebox can be defined. The timebox for the project
is based on the set of in-scope user stories and the
estimated time to complete each feature and the actual
project team composition. The project timebox defines the
overall budget for the project in terms of resources and
number of days to deliver the defined functionality. At
OutSystems, we adhere to the timebox principle --- we hold
the budget and the timeline sacred for each project and
each sprint that makes up the project. In other words, the
budget and timeline are fixed.
To be truly Agile in the budgeting stage, we use the Agile
Sizings component of the Agile Network. The Agile Sizings
component allows us to scope a project based on heuristics
accumulated from over 500 highly successful Agile projects.
This tool automates the sizing calculations based on
patterns, as well as project and application parameters.
When the sizing is complete, the Sizing tool provides the
initial project plan as defined by the OutSystems approach
to Agile.

2. Project Initiation
The Project Initiation stage is where we start the actual
project. We take the user stories and features then load
them into the Agile Projects component of the Agile
Network. This is called bootstrapping the project. The user
stories and features are now loaded into the project backlog.
The project backlog is the list of requirements to be
delivered. Once the project is bootstrapped we then
conduct a kick-off meeting to bring everyone up-to-speed
on the project scope, roles, responsibilities, risks, sprint
demo session dates, etc.
At this point, we can apply scope analysis. Scope analysis
involves more detailed requirements analysis including
external interface analysis for dependencies. Scope analysis
also involves prioritizing the requirements based on the
value they provide to the business. We ask questions like:

2001-2012 OutSystems ---- All rights reserved

Page 2 of 4

As part of the project bootstrapping process, the project

sprints are identified in the Agile Projects component. A
sprint is an iterative cycle of about 2-3 weeks in which a
portion of the application is developed. At the end of each
sprint, the project team delivers a working, vertically
integrated portion of the final application. The length of a
sprint is defined in the original plan provided through the
Agile Sizings component.
Throughout the remainder of the project, the Agile Projects
component will be the primary tool used for managing the
day-to-day tasks of the project. This component is
composed of various tools to facilitate project initiation,
planning, execution, controlling, reporting and closure. It
includes specific tools for managing Agile projects like
backlog management, sprint planning, requirements
management, etc.

3. Iterative Development (Sprints)

Sprint planning is the first major activity of the iterative
development stage. The sprint planning activity involves
reviewing the project backlog and collaborating with the
business team members to decide which user requirements
will be included in the current sprint. This process is called
Sprint Backlog Settlement. During this process, feature
negotiation and prioritization takes place between the
Engagement Manager and the Business Manager to
establish priorities for the sprint and balance the overall
project time box.
The goal of Sprint Backlog Settlement is to identify the highvalue requirements to be included in the sprints backlog
without exceeding the sprints timebox. Once the sprint
backlog is defined, a detailed analysis of the requirements is
conducted. By further detailing the requirements to define
their design and implementation approach, it will become
evident that some may be impossible to implement or
alternative implementations may need to be identified. The
impact of these changes need to be assessed to determine if
these requirements need to be shifted to the next sprint or
lesser value requirements be removed from the sprint
backlog. Remember, we hold the timebox sacred for each
sprint and the overall project.
All through the sprint planning activity, the Agile Projects
component is used to record the sprint backlog, change
www.outsystems.com

requests, issues and risks that arise because of the

continuous planning process.

that the application delivered meets the needs of the

business.

The Development and Testing activity begins in each sprint

once the sprint backlog is settled. At the start of this activity,
the Delivery Manager and each member of the delivery
team works together to detail the design, identify the tasks,
make delivery commitments and finalize the expected effort
for each of the assigned work items. As the team progresses
in developing and testing the features, they do so using the
visual design and development approach provided by the
OutSystems Agile Platform core components --- Integration
Studio, Service Studio and Service Center.

A note about teams, roles, and responsibilities:

On a daily basis, the Delivery Manager conducts a 15-minute

standing-only Scrum meeting to synchronize the teams
direction. At least once a day or more frequently, all team
members upload their work to the Agile Platform and
integrate with the other team members work, ensuring that
all work completed is made available to the rest of the team.
The projects Delivery Manager uses the Agile Projects
component to manage the teams workload. Similarly, each
team member uses the Agile Projects component to record
completed effort against each work item on his or her task
list.
At the end of each Sprint, the delivery team provides a
demonstration of the working application to the business
team members. At this time, a vertically integrated version
of the application is presented to the Business Manager and
key business users. During each demo session, the end
users and QA team members will provide feedback using
the Agile Platforms Embedded Change Technology (ECT) so
that all input goes directly to the Agile Projects component
for immediate assessment and possible addition to the
projects backlog.
Beginning with the initial sprint, the formal demo signals the
start of what we call the Continuous User Acceptance
process. Because sprints are short and frequent, the users
and Quality Assurance engineers will be continuously
testing the delivered application functionality and
identifying issues, enhancements and functional errors. This
shift in testing greatly enhances application quality and user
adoption. Once the demo is completed, the set of features
accepted by the Business Manager are signed off and closed.

The responsibilities of a Project Manager or a Scrum Master

are divided between the Engagement Manager and Delivery
Manager. In keeping with the need for greater and constant
business involvement while at the same time setting and
managing expectations, the Engagement Manager becomes
the conduit for the business. The Engagement Manager will
need to fully understand the end-to-end process as well as
the business vision.
The Engagement Manager represents the business to the
Delivery Manager who aligns the developers with the
business need. The Delivery Team, which is headed by the
Delivery Manager, is responsible for delivering the features
agreed upon while keeping true to the timebox. It is
therefore imperative that the Engagement Manager and
Delivery Manager work in concert to ensure that the
solution delivered meets the needs of the business.
One of the checks and balances that this model affords is
that the Engagement Manager can ensure that the Delivery
Manager delivers as expected while the Delivery Manager
can ensure the Engagement Manager does not over commit.

4. Training
The training stage is where we pass ownership of the
application to the business. In a typical training session,
students are taught how to use the application. The focus is
on making sure students learn. The OutSystems approach to
Agile takes a different slant on training. The focus is on
getting extended feedback about the application. Thus,
training is a two step process.
First we train key business users and front-line individuals
that will carry on the work to assist all other users in learning
to use the application. In a well designed and intuitive
application, users learn the application with minimal to no
formal training. Second, which is the main focus of training,
is to enable and empower these key individuals to receive
and provide feedback so that the application can continue
to evolve as the business evolves. As the number of users
grow, there will be more feedback to evolve and improve

Any changes or new requirements are logged into the

project backlog and discussed during the next sprint
planning session. Whether or not these are incorporated
into the next sprint backlog is discussed during feature
negotiations. It should be noted that new requirements or
changes of higher priority will inevitably displace lower
priority items that are in-scope. This is to be expected. This
is one of the benefits of the OutSystems approach to Agile.
By constantly aligning with the business, we can be assured
2001-2012 OutSystems ---- All rights reserved

The OutSystems Agile approach looks at the project team as

composed of two teams --- the Engagement Team and the
Delivery Team. The Engagement Team is composed of the
Business Manager, Users, and the Engagement Manager
while the Delivery Team is composed of the Delivery
Manager and the Developers. Developers include all the
technical roles required for the project.

Page 3 of 4

www.outsystems.com

the application keeping the application in pace with

business and process changes.

feedback from the users through the Embedded Change

Technology.

Feedback is encouraged through the Embedded Change

Technology (ECT) mechanism which is built into every
application. Using ECT all user feedback will automatically
be logged to minimize disruption in the rollout process and
subsequently during everyday use.

While the developers are busy pushing new versions to

production, the application, system and network
administrators are conducting performance tuning to
ensure that the application and the environment meet or
exceed service levels. In performing the tuning tasks, the
delivery team continuously uses the OutSystems Agile
Platform components --- Integration Studio, Service Studio
and Service Center as appropriate. At OutSystems, we
believe that the success of a project equates to being OnTime, On-Budget and have 100% User Adoption.

5. Production Launch
During production launch, the application is published to
production using the Agile Platforms 1-click publishing
technology. Depending on the nature of the application,
the production launch might be targeted to a limited set of
users and be running in parallel with any replacement
systems. As soon as the application is in production, the
delivery team begins tuning the application. This stage is a
mandatory part of our Agile approach and is critical in
preparation for full application rollout and end-user
adoption.

7. Wrap-Up
The wrap-up stage officially closes the project. During wrapup the tuned application is fully signed-off in production.
Using the Agile Projects component, all remaining project
backlog items are discussed and either archived, prepared
for the next release of the application or identified as items
to be applied during the maintenance stage.

6. Tuning
The tuning stage is a key part of the OutSystems Agile
approach. It is based on our accumulated experience across
500+ successful projects. During this special sprint, two key
activities are conducted --- application performance and
functional tuning. During functional tuning, outstanding
issues are resolved and any remaining low-priority project
backlog items are assessed for delivery. These items are
assessed to determine if they can be considered as
adoption boosting functionality. Adoption boosting
features increases the probability of the users liking and
immediately using the new application.
From the delivery teams perspective, this stage is very
intense. There will typically be multiple production
deployments each day using the 1-click-publish feature of
the Agile Platform as the team conducts functional tuning.
The intent of multiple deployments is to resolve any
outstanding issues and to implement as many "adoption
boosting" features as possible, while continuously collecting

2001-2012 OutSystems ---- All rights reserved

Page 4 of 4

8. Maintenance
The objective of the maintenance stage is to ensure that the
application continuously supports the business through
evolutionary maintenance. This means that as the business
changes, so should the application. Therefore, this stage
consists of a series of 1 to 2 week sprints depending on the
changes or new features identified in an ongoing basis.
These sprints continue to follow all the primary activities in a
regular sprint and leverage all the necessary tools required
to keep the delivery team Agile.
At OutSystems, we believe that the promise of Agile cannot
be fully realized without enabling technology that shortens
delivery cycles, increases software development agility,
project predictability, responsiveness to business change
and overall development team productivity.

At OutSystems, it is all about Agility!

www.outsystems.com