Agile Software Development Life Cycle: © 2017 Amdaris Group LTD

Agile Software
Development Life Cycle
© 2017 Amdaris Group LTD All rights reserved. Amdaris are Microsoft Gold Partners in Application 1
Development and are certified under ISO 9001 and ISO 27001
Contents
Contents ...............................................................................................................................................................................1
Agile Software Development Life Cycle...................................................................................................................... 3
Programme Initiation and Start-up Phases ........................................................................................................... 3
Programme Initiation .............................................................................................................................................. 4
Start-up Phase .......................................................................................................................................................... 5
Requirements................................................................................................................................................................. 6
Definition of Ready and Definition of Done ..................................................................................................... 7
Development ................................................................................................................................................................. 7
Code Development ................................................................................................................................................. 8
Agile Ceremonies..................................................................................................................................................... 8
The concept of WIP limit ...................................................................................................................................... 11
Continuous Integration and branching strategy ................................................................................................ 11
Release Phase .............................................................................................................................................................. 13
Confidentiality & Disclaimer Notice ........................................................................................................................... 14
© 2017 Amdaris Group LTD. All rights reserved. Amdaris are Microsoft Gold Partners in 2
Application Development and are certified under ISO 9001 and ISO 27001
Agile Software Development Life Cycle
In order to achieve the objectives of the software development programme, Amdaris proposes a
collaborative partnership that will involve all aspects of an Agile Software Development Life Cycle.
Over the years based on best practices and lessons learned, Amdaris has developed an Agile
Software Development Life Cycle methodology. The methodology is split into several phases:
 Programme Initiation and Start-up Phase

 Requirements Gathering
 Development
 Continuous Integration
 Release
Programme Initiation and Start-up Phases
The Programme Initiation and Start-up Phases are the first steps and vital parts in the software
development life cycle. It creates the foundation, plan and a common understanding of the future
development activities. For both Programme Initiation and Set-up Phase Amdaris will focus on 4 areas
of the programme:
 Business Engagement
 Solution Design
 Programme Management
 Drive the Programme
Programme Initiation
The main purpose of this phase is to agree the business outcomes for each areas as per table below.
Agreed business outcomes
At programme initiation Amdaris will discuss the top-level outcomes of the

Business
programme with the client and establish a vision for the programme that will
Engagement
be communicated to all.
Amdaris will work with the client to dive deep into the business, determine the
top level aims of the solution and understand its current state. We’ll discuss and
Solution Design
agree architectural and design principles, data strategy, hosting strategy and
top-level features and business priorities.
A plan will be agreed identifying specific resource and setting the outline of
Programme
how to share best practice during the lifetime of the programme. A top-level
Management
governance and communication plan will be discussed and agreed.
A new way of working will be established, identify what skills and capability will
be needed to achieve the change, understand if any current ways of working
Drive the
are incompatible with the new approach and explore ways of dealing with
programme
these. Ensure that the business is in a prepared and ready state to start the
programme.
Start-up Phase
The main purpose of this phase is to run activities which will prepare the programme in all areas as
per table below.
Prepare the programme
At programme start-up Amdaris will work with the client to establish the
Business
business requirements, establish and communicate mechanisms for ongoing
Engagement
assurance, create and communicate the programme roadmap.
Agree a high-level solution based on the combination of established and
Solution Design known requirements with any new requirements. The programme team will
gather and validate business requirements and create acceptance criteria.
The programme management team will develop a programme plan, design
Programme
and implement the development approach and communicate the outcomes
Management
to stakeholders at all levels.
This will involve managing stakeholder’s expectations and communicating the
Drive the
way the programme will be implemented, identifying programme champions
Programme
and leaders within the client.
Requirements
All the requirements gathered by the Business Analysts will be categorised in two groups, functional
requirements and non-functional requirements.
Amdaris’ and the client’s product owners will generate functional requirements as part of the project
initiation phase. Each functional requirement will be complemented with supporting documentation,
as needed:
 User stories
 Acceptance criteria
 Flow diagrams
 Visual acceptance criteria, such as designs and wireframes.
The team in collaboration with the client will agree on the priority for the requirements and will
stablish the deadlines for the releases as per diagram below.
Definition of Ready and Definition of Done
Each requirement in order to be passed to the development team will comply the standard agreed by
the team in the document called Definition of Read. After the development the requirements is
considered done if it complies with the stands agreed by the team in the document called Definition
of Done.
Development
In this phase the development activities are organised across four dimensions:
1. Code development
2. Agile ceremonies
3. Continuous integration
4. Release plan
The image below graphically represents this stage:
Code Development
This is an important part of the software development lifecycle and the main objective is to maintain a
high level of code production. The following activities will be put in place to assure the quality of the
code:
1. Code and unit test writing

2. Integration test writing
3. Pull requests and code review
4. Manual testing of the stories based on acceptance criteria and visual acceptance criteria.
5. Writing automation tests
6. Performing compatibility tests
7. Documentation the code
8. Deploy on system test
Agile Ceremonies
During the development of the product, Amdaris proposes the use of Agile ceremonies as follow:
Daily Stand-up (Scrum meetings)
Frequency Once per day, time limited to 15 min.
A regular meeting to answer the following questions:
What did I do yesterday?

Description
What I will do today?
What impediments do I have?
Scrum Master and development team. The product owner, architect, designer
Participants
and other consultants are optional.
A clear understanding of the worked needed to be done, escalation of issues

Outcome
and blockers.
Sprint Planning
Once per sprint, 4-hours maximum, usually held on the last day of the previous
Frequency
sprint or on the first day of the current sprint.
The meeting is divided into two parts:
Part 1:
 Discuss team capacity
 Discuss user stories with development team
 Estimate stories in points
Description  Move stories from Product backlog into Sprint backlog
according to PO priority and team velocity
 Set up a Sprint goal
Part 2:
 Split the stories into tasks
 Estimate tasks in hours.
For the part 1: SM, PO and development team.
Participants For the part 2: Tasks can be decided inside development team, SM and PO are
optional for this part.
Outcome Sprint backlog.
Sprint Review (Demo)
Frequency Once per sprint, 2-hour maximum, at the end of each sprint
This is a presentation of work completed by the team that is ready to be

Description delivered. The feedback can be used to update the product backlog with new
requirements.
Participants SM, PO and development team, other stakeholders.
Outcome Early feedback, new requirements.
Retrospective
Once per sprint, 2-hour maximum, at the end of each sprint. It is recommended
Frequency
that the retrospective is immediately done after a sprint review.
Discuss issues, decide on actions for improvement, give positive feedback,
congratulate each other for success and achievements. Each member provides
feedback anonymously by answering the following 2 questions:
Description
 “What went well?”
 “What can be improved?”
After that the whole team agrees on an action plan for the improvements.
Participants SM, PO and development team.
Outcome Improvement Action Plan.
Requirement Refinement (Optional)
1-2 sessions per sprint with no more than 2-hours per session. They can be held
Frequency
at any time during the sprint.
Discuss user stories for future sprints with the development team and to help in
Description
the estimation of stories.
Participants SM, PO and development team.
Outcome Chances to the stories or acceptance criteria.
The concept of WIP limit
A WIP (work in progress) limit is a strategy for preventing bottlenecks in software development.
Amdaris proposes that the work in progress limits are agreed upon by the development team before
a project begins and are enforced by the team's facilitator (scrum master). For example, a team may
divide the tasks that must be performed for a feature into design, code, test and deploy. When a WIP
limit for a certain task has been reached, the team stops and works together to clear the bottleneck.
The goal of working in this manner is meant to ensure that the entire team takes ownership of the
project and produces high quality code.
Continuous Integration and branching strategy
Continuous Integration (CI) is a development practice that requires developers to integrate code into
a shared repository several times a day. An automated build, allowing teams to detect problems early
and then verifies each check-in. By integrating regularly, errors can be detected quickly and located
more easily.
Continuous Integration brings multiple benefits to an application development:
 Removes long and tense integrations

 Increases visibility which enables greater communication
 Catches issues quickly and solves them quickly
 Less time is spent for debugging and more time for adding features
 Brings confidence that the build is on a solid foundation
 Reduces integration problems allowing to deliver software more rapidly
Continuous Integration is backed by several important principles and practices listed below:
 Maintain a single source repository

 Automate the build
 Make the build self-testing
 Every commit should build on an integration machine
 Keep the build fast
 Test in a clone of the production environment
 Make it easy for anyone to get the latest executable
 Everyone can see what’s happening
 Automate deployment
How to do it:
 Check in frequently
 Don’t check in broken code
 Don’t check in untested code
 Don’t check in when the build is broken
 Wait after the checking in, until the system is built
Many teams develop rituals around these policies, meaning the teams effectively manage themselves,
removing the need to enforce policies on the developers.
To achieve an effective continues integration Amdaris is using an effective branching strategy based
on Branch per feature approach. Each new functionality is developed in isolation from the main
branch and then merged back following security gates like pull request, code review, gated check-in.
This strategy assures that the main branch always stays green and the build which are upgraded to
system test and UAT are always functioning.
Release Phase
At the end of the development phase, there will be a code freeze and a release candidate for the
Minimum viable product (MVP) will be identified. The release candidate will go through a series of
testing and bug fixing. The main activities will include:
 UAT testing (User Acceptance Testing)

 Load testing
 Stress testing
 Security testing
 Performance testing
After the successful testing and acceptance, the release candidate will be upgraded to version 1.0 and
will be deployed on the live environment. Every live release will be accompanied by release notes,
which will clearly state what was delivered.
There will be other activities associated with the release of the software like:
 Documentation
 User manual
 Training of help desk
 Internal communication
 External communication
Confidentiality & Disclaimer Notice
This document has been prepared by Amdaris for the sole use of the recipient.
The information contained in this documentation is proprietary and confidential to Amdaris and should be kept confidential
and not disclosed by the recipient to any other person unless such person has a need to know such information in order to
evaluate the contents of this document.
Amdaris has prepared this document in good faith based on the information made available by the recipient to Amdaris and
Amdaris reserves the right to make amendments and to correct any errors that are identified.
Nothing in this document or in any related correspondence, discussions or other materials shall be construed as the basis of
any contract or a representation which may be relied upon by the recipient unless agreed by Amdaris in the context of a
legally binding agreement. No warranty, assurance or undertaking (express or implied) is or will be made, and no
responsibility or liability is or will be accepted by Amdaris or any persons employed or engaged by Amdaris in relation to the
adequacy, accuracy, completeness or reasonableness of the contents of this document, or of any other information (whether
written or oral), notice or document supplied or otherwise made available to the receipt and, to the maximum extent
permitted by applicable law, all and any such responsibility and liability is expressly disclaimed.
The following notice applies to this document and should be reproduced by the recipient on any copies which have been
made in accordance with this notice.
Ready to find out more?
0117 935 3444
ask@amdaris.com

Agile Software Development Life Cycle: © 2017 Amdaris Group LTD

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Agile Software Development Life Cycle: © 2017 Amdaris Group LTD

Uploaded by

Copyright:

Available Formats

Agile Software

Development Life Cycle

 Programme Initiation and Start-up Phase

Programme Initiation and Start-up Phases

Agreed business outcomes

At programme initiation Amdaris will discuss the top-level outcomes of the

Prepare the programme

The image below graphically represents this stage:

1. Code and unit test writing

Daily Stand-up (Scrum meetings)

Frequency Once per day, time limited to 15 min.

A regular meeting to answer the following questions:

What did I do yesterday?

What impediments do I have?

A clear understanding of the worked needed to be done, escalation of issues

Outcome Sprint backlog.

Sprint Review (Demo)

This is a presentation of work completed by the team that is ready to be

Participants SM, PO and development team, other stakeholders.

Outcome Early feedback, new requirements.

Participants SM, PO and development team.

Outcome Improvement Action Plan.

Requirement Refinement (Optional)

Participants SM, PO and development team.

Outcome Chances to the stories or acceptance criteria.

Continuous Integration and branching strategy

Continuous Integration brings multiple benefits to an application development:

 Removes long and tense integrations

 Maintain a single source repository

 UAT testing (User Acceptance Testing)

You might also like