Scrum under PRINCE 2

1. Scrum - Agile Model Under PRINCE 2
Agile is an iterative and incremental (evolutionary) approach to software development which is
performed in a highly collaborative manner by self-organizing teams with just enough
ceremony that produces high quality software in a cost effective and timely manner which
meets the changing needs of its stakeholders.
• Agile
Principles of Agile Model
Flavors of Agile Model
SDLC Process Overview Under Agile
• Scrum - Agile Model
Uderlying principles of Scrum
Flow of activities in a Scrum
Scrum SDLC Overview Under PRINCE2
Scrum SDLC And Artefacts Under PRINCE2
• Demystifying Scrum SDLC Stages
Project Approval
Pre Analysis
Initiating
Execution
Managing Stage Boundaries
Closing
Post Production
• Author
Agile
The modern definition of agile software development evolved in the mid 1990s as part of a
reaction against heavyweight methods, as typified by a heavily regulated, regimented, micro-
managed use of the waterfall model of development. The processes originating from this use of
the waterfall model were seen as bureaucratic, slow, demeaning, and inconsistent with the
ways that software engineers actually perform effective work. A case can be made that agile
and iterative development methods are a return to development practice seen early in the
history of software development.Initially, agile methods were called lightweight methods. In
2001, prominent members of the community met at Snowbird, Utah, and adopted the name
agile methods. Later, some of these people formed The Agile Alliance, a non-profit
organization that promotes agile development.
More on Agile can be found here
Principles of Agile Model
Agile Model is a family of various development processes, its not a single approach to software
development. These processes under agile umberella are driven by Agile Principles known as

2. Agile Manifesto, widely regarded as the canonical definition of agile development.
Some of the principles behind the Agile Manifesto are:
• Customer satisfaction by rapid, continuous delivery of useful software
• Working software is delivered frequently (weeks rather than months)
• Working software is the principal measure of progress
• Even late changes in requirements are welcomed
• Close, daily, cooperation between business people and developers
• Face-to-face conversation is the best form of communication
• Projects are built around motivated individuals, who should be trusted
• Continuous attention to technical excellence and good design
• Simplicity
• Self-organizing teams
• Regular adaptation to changing circumstances
More on Agile Manifesto can be found here
Flavors of Agile Model
Under this broad umbrella sits many more specific approaches such as
Extreme Programming
Scrum
Lean Development
Feature Driven Development

3. SDLC Process Overview Under Agile
Scrum - Agile Model
Scrum is a term which comes from the game of Rugby where high-performing teams form the
scrum.
Uderlying principles of Scrum
A product backlog of prioritized work to be done;
Completion of a fixed set of backlog items in a series of short iterations or sprints;
A brief daily meeting or scrum, at which progress is explained, upcoming work is
described and impediments are raised.
A brief sprint planning session in which the backlog items for the sprint will be
defined.
A brief sprint retrospective, at which all team members reflect about the past
sprint.
Flow of activities in a Scrum
Scrum is used as an Agile Model of Software Development. The governing process framework
around this development model is
a project management methodology known as Prince 2 - Projects in Controlled
Environments (PRINCE).
Under the PRINCE2 governing process framework SCRUM SDLC is defined in 7 Steps.

4. Scrum SDLC Overview Under PRINCE2
Following are the stages/steps :
1. Project Approval - Mandate
2. Pre Analysis
3. Initiating
4. Execution
5. Managing Stage Boundaries
6. Closing
7. Post Production
Scrum SDLC And Artefacts Under PRINCE2
Shown below is a full overview of all the stages and artefactes required.
Note: Processes are in yellow color and SDLC artefacts are in pink color.

5. Demystifying Scrum SDLC Stages
Project Approval
Pre Analysis
Initiating
Execution
Managing Stage Boundaries
Closing
Post Production
Project Approval
This stage is all about having a vision for what is to be achieved in coming years and how this
can be realized.
Note: Items in yellow are not artefacts, they represent the process which takes place during
this stage. Artefacts are the outcomes from these process. Item in orange is a Gate for Prince
2.
• Artefacts
Artefacts
No artefacts are required for this stage.

6. Pre Analysis
Pre Analysis is a stage to provide a full and firm foundation for the initiation of the project. The
contents of the Initiative Brief will be extended and refined into the Project Initiation Document
(PID), which is the working document for managing and directing a project. The Project Brief
contains the outline plan for the Initiation process and forms the basis of the schedule and
resource requirements for that process. The Project Brief is a document in its own right and is
the basis of the PID.
Note: Items in yellow are not artefacts, they represent the process which takes place during
this stage. Artefacts are the outcomes from these process. Artefacts marked as Mandatorty are
required from project management perspective. They are required under Prince 2 Governance
Framework, they are not SDLC deliverables. Item in orange is a Gate for Prince 2.
• Artefacts
High Level Business Case/ Initiative Brief
Buisiness Case
Initiative Brief
Project Approach Recommendation
Risks Log
High Level Business Case/ Initiative Brief
Buisiness Case
A high level business case represents what benefits will the business get out of this project,
how much will it cost to the business and what are the risks associated with it. The business
case will forecast effort and time and whether it is worth the expenditure. This analysis is a part
of inititaive brief.
Initiative Brief
This is to provide a full and firm foundation for the initiation of the project. The contents of the
Project Brief will be extended and refined into next stage M2 - Project Initiation Document,
which is the working document for managing and directing a project. The Initiative brief
contains the outline plan for the Initiation process (M2) and forms the basis of the schedule and

7. resource requirements for that process. The Initiative brief is a document in its own right and is
the basis of Next Stage M2 (PID)
Both are mandatory artefacts produced by PMO.
Project Approach Recommendation
This is to define the type of solution (what) to be developed by the project and/or method of
delivering(how) that solution. It should also identify any environment into which the solution
must fit.
This is a mandatory artefact produced by PMO and is a part of Initiative
Brief/Project Breif.
Note: For smaller projects this may form part of the Project Brief. This needs to be agreed with
the Corporate Program Office when Starting Up a Project.
Risks Log
The purpose of the Risk Log is to contain all information about the risks, their analysis,
countermeasures and status. Risks should be considered during the creation of key documents.
There should be a check for new risks every time the Risk Log is reviewed, minimally at the end
of each stage. The Project Steering Committee has the responsibility to check external events
continually for external risks
This is a mandatory artefact produced by PMO and is a part of Initiative
Brief/Project Breif.
Initiating
To define the project, to form the basis for its management and the assessment of overall
success. The Project Initiation gives the direction and scope of the project and forms the
contract between the project management team and corporate program management. It is
essentially a compilation of key project information and documents to date, including the
detailed Business Case (evolved from initial Business Case); Product Backlog (evolved fom User
Stories), Risk ans Issues Log, Architecture Solution, Technology Used and Development
Roadmap

8. Note: Items in yellow are not artefacts, they represent the process which takes place during
this stage. Artefacts are the outcomes from these process. Artefacts marked as Mandatorty are
required from project management perspective. They are required under Prince 2 Governance
Framework, they are not SDLC deliverables. Item in orange is a Gate for Prince 2.
Note: SDLC deliverables are marked as non mandatory, this doesn't mean they are not be
produced. SDLC artefacts needs to be produced, only difference is their are no
standard templates required. Whatever can be adapted to deliver it will be fine.
• Artefacts
Detaild Business Case
Product Backlog/User stories
Risk and Issues Log
High Level Solution Architecture
Technology Used
Infrastrucure Requirements
Development Roadmap
Estimates
Artefacts
Detailed Business Case
The justification for undertaking the project based on the estimated cost of development and
implementation against the risks and the anticipated benefits. The total business change must
be considered, which may be much wider than just the project development cost. The Business
Case is used to say why the forecast effort and time will be worth the expenditure. The Project
Steering Committee will monitor the ongoing viability of the project against the Business Case.
This is a mandatory artefact produced by PMO and is part of Project Initiation
Document - PID.
Product Backlog/User stories
Products backlog is nothing but a collection of user Stories. This is equivalent of High Level
Buisness Requirement Specification (BRS)
This is a mandatory artefact

9. Risk and Issues Log
Risks Log The purpose of the Risk Log is to contain all information about the risks, their
analysis, countermeasures and status. Risks should be considered during the creation of key
documents. There should be a check for new risks every time the Risk Log is reviewed,
minimally at the end of each stage. The Project Steering Committee has the responsibility to
check external events continually for external risks
Project Issues A generic term for any matter that has to be bought to the attention of the
project team and requires an answer. After receiving a unique reference number, Project Issues
are evaluated in terms of impact on the product, effort, cost, risks, Project Plan and Business
Case. The Project Manager may make a decision on what action to take or the Project Issue
may be referred to the Project Steering Committee. A Project Issue may have a negative or
positive impact on the project.
Issue Log Project Issues are raised as required and are an input into / recorded in the Issue
Log.
This is a mandatory artefact produced by PMO and is part of Project Initiation
Document - PID.
High Level Solution Architecture
High level solution architecture comprises of high level view of componets interacting with each
other in a system (it can be a multiered, distributed, standalone.)
Note: SDLC Artefact - their is no standard template required for this. Agile is about being
adaptive, its upto you how you want to do it. As along as it is created in some form and
visible to all the team members its fine.
An example of High Level Solution Architecture can be found here ?
Technology Used
This is to describe in a system which component will be using what technoloy or its
implementaion framework/library.
Note: SDLC Artefact - their is no standard template required for this. Agile is about being
adaptive, its upto you how you want to do it. As along as it is created in some form and
visible to all the team members its fine.
Infrastrucure Requirements
It comprises of hardware, software required for development, testing and production. Is also
includes system security considerations, network, backup and disaster recovery plans.
Note: SDLC Artefact - their is no standard template required for this. Agile is about being
adaptive, its upto you how you want to do it. As along as it is created in some form and
visible to all the team members its fine.

10. An example of Infrastrucure Requirements can be found here ?
Development Roadmap
It describes how a product will be evolved dutring the project life cycle. It will lay out the road
map for the product life cycle pointing out when various functionalities or features will be
available.
Note: SDLC Artefact - their is no standard template required for this. Agile is about being
adaptive, its upto you how you want to do it. As along as it is created in some form and
visible to all the team members its fine.
Estimates
Estimates are carried out to identify how many man days will be required to undertake the
project. It is always a difficult execrice to predict the accurate number
Note: SDLC Artefact - their is no standard template required for this. Agile is about being
adaptive, its upto you how you want to do it. As along as it is created in some form and
visible to all the team members its fine.
Execution
At this stage development phse kicks in with planning and design for the sprint. Developemnt is
test driven (TDD) i;e - first write a test case and then develop the component until your tes
case passes. System Test and Fucnctional Test are executed in later part of sprint. In addition
to this a users guide or operations guide is prouced at end of the sprint/
Note: Items in yellow are not artefacts, they represent the process which takes place during
this stage. Artefacts are the outcomes from these process. Artefacts marked as Mandatorty are
required from project management perspective. They are required under Prince 2 Governance
Framework, they are not SDLC deliverables. Item in orange is a Gate for Prince 2.
Note: SDLC deliverables are marked as non mandatory, this doesn't mean they are not be
produced. SDLC artefacts needs to be produced, only difference is their are no
standard templates required. Whatever can be adapted to deliver it will be fine.

11. Artefacts
Sprint BackLog
The sprint backlog is the list of tasks that the Scrum team is committing that they will complete
in the current sprint. Items on the sprint backlog are drawn from the Product Backlog, by the
team based on the priorities set by the Product Owner and the team's perception of the time it
will take to complete the various features.
It is critical that the team selects the items and size of the sprint backlog. Because they are the
ones committing to completing the tasks they must be the ones to choose what they are
committing to.
The sprint backlog is very commonly maintained as an Excel spreadsheet but it is also possible
to use your defect tracking system or any of a number of software products designed
specifically for Scrum or agile.
During the Sprint the ScrumMaster maintains the sprint backlog by updating it to
reflect which tasks are completed and how long the team thinks it will take to
complete those that are not yet done. The estimated work remaining in the sprint is
calculated daily and graphed, resulting in a sprint burndown charrt.
Note: SDLC Artefact - their is no standard template required for this. Agile is about being
adaptive, its upto you how you want to do it. As along as it is created in some form and
visible to all the team members its fine.
Sprint Burn Down Chart
The Sprint Burndown chart gives the team a daily indication of their velocity and progress
against the work they have committed to for the current Sprint. Even early on in a Sprint, the
burndown chart gives the team a good idea of how they're progressing against their Sprint
tasks and whether they will complete them by the end of the Sprint. This both keeps up the
motivation to deliver on the work they have committed to and also provides a planning tool to
aid decisions. In simple terms it is graphical the representation of the total tasks undertaken for
the sprint versus sprint time.
Note: SDLC Artefact - their is no standard template required for this. Agile is about being
adaptive, its upto you how you want to do it. As along as it is created in some form and
visible to all the team members its fine.
Flow Diagrams, Schema Desgin, Screen Mock Ups
As a result of sprint design phase, flow diagram, class diagrams, schema design or sceen mock
ups are produced.These are produced in various forms and their is not a standard format or
template. As long as they are captured and made visible to team members its fine. Its all about
visibility and making sure we are getting on righ track (in design and solution terms).

12. Note: SDLC Artefact - their is no standard template required for this. Agile is about being
adaptive, its upto you how you want to do it. As along as it is created in some form and
visible to all the team members its fine.
Code Review Checklist
Code reviews are carried out to make sure that design mistakes are not carried, best practices
are used, components are extensible and robust. Some aspects of the code health check are
build into Conitnuous integration build tool used for the sprint.
Refactoring is mostly carried out after code reviews.
Note: SDLC Artefact - their is no standard template required for this. Agile is about being
adaptive, its upto you how you want to do it. As along as it is created in some form and
visible to all the team members its fine.
Unit Test Suite
Unit Test suite is a colloection of all unit tests created during the sprint. These unit tests are
automated test that ensures that the functionality required for a certain area of a project is
implemented, and that there are no breaking changes that have not been taken into
consideration Their is no tempalte for this, but it is a vital artefact for Test Driven Development
(TDD) approach.
Note: SDLC Artefact - their is no standard template required for this. Agile is about being
adaptive, its upto you how you want to do it. As along as it is created in some form and
visible to all the team members its fine.
System Test Cases
System test cases are mapped from Functional Specification.
Note: SDLC Artefact - their is no standard template required for this. Agile is about being
adaptive, its upto you how you want to do it. As along as it is created in some form and
visible to all the team members its fine.
UAT Cases
User acceptance test cases are mapped out of BRS. It is an exercise carried out by end
customer.
Note: SDLC Artefact - their is no standard template required for this. Agile is about being
adaptive, its upto you how you want to do it. As along as it is created in some form and
visible to all the team members its fine.
This artefact is maintained by a Business Analyst.
Example for UAT can found here.

13. Users/Operations Guide
Users or Operations Guide is a vital artefact delivered to end customer. It covers all the aspects
about product/system developed during execution phase. For customer its the only document
for them to guide, how to interact and use the product.
This is a mandatory artefact produced by PMO.
Managing Stage Boundaries
This is not a stage in SDLC, but it is a checkpoint in SDLC to make further decisions. It is run
just after finishing execution stage sprint and is considered part of execution stage. Once the
execution sprint is finished, busines case is analyzed again with its known risks, issues and cost
assocaited with it. Risk and Issue logs are updated in tandem with business case. Product
backlog is updated again from Initiating Stage to see what features are covered and what are
remaining. A new sprint backlog and burn down chart is created to , priortize tasks and see
what tasks can be covered in esitiamted time. From second Execution Sprint (i;e; 2.2 not 2.1))
onwards regression tests are created and updated from here onwards.
After analyzing all these artefacts a decision is made to continue the projcet or close the
projcet. If it continues then Execution Stage (M2.1) is repeated which becomes(M2.2),
otherwise project is closed, hence closing stage is reached.
Note: Items in yellow are not artefacts, they represent the process which takes place during
this stage. Artefacts are the outcomes from these process. Artefacts marked as Mandatorty are
required from project management perspective. They are required under Prince 2 Governance
Framework, they are not SDLC deliverables.
Note: SDLC deliverables are marked as non mandatory, this doesn't mean they are not be
produced. SDLC artefacts needs to be produced, only difference is their are no
standard templates required. Whatever can be adapted to deliver it will be fine. Item in
orange is a Gate for Prince 2.
• Artefacts
Update Business Case
Update Risk and Issues log
Update Prodcut Backlog
Create Sprint Backlog
Create Burn Down Chart
Add and Update Regression Tests

14. 1.1 Artefacts
Update Business Case
Busines case created in Initiating Stage is updated to see whether the project is still beneficial
for the organization with its known risks, issues and cost assocaited with it.
This is a mandatory artefact produced by PMO.
Update Risk and Issues log
As the business case is updated, risk and issues log are updated which were created in
Initiating Stage.
This is a mandatory artefact produced by PMO.
Update Prodcut Backlog
Product Backlog created in Initiating Stage is updated to see what features are covered and
what are remaining.
This is a mandatory artefact produced by PMO.
Create Sprint Backlog
Their is no activity in SDLC which doesn't consume time and effort. In order to make a good
decision necessary artefacts are created to to make a decision. Creating these artefacts require
time and effort. So a new Sprint backlog is created for this stage to see what tasks are
remaining and what can be covered.
Note: SDLC Artefact - their is no standard template required for this. Agile is about being
adaptive, its upto you how you want to do it. As along as it is created in some form and
visible to all the team members its fine.
Create Burn Down Chart
A new Sprint Burn down chart is created for this stage to monitor the progress of the sprint.
Note: SDLC Artefact - their is no standard template required for this. Agile is about being
adaptive, its upto you how you want to do it. As along as it is created in some form and
visible to all the team members its fine.

15. Add and Update Regression Tests
Regression testing is any type of software testing which seeks to uncover regression bugs.
Regression bugs occur whenever software functionality that previously worked as desired, stops
working or no longer works in the same way that was previously planned. Typically regression
bugs occur as an unintended consequence of program changes.
Regression tests are added and updated further after executing Sprint 2 not Sprint 1, that is
after completing Execution Stage second time. Reason for that is; that at end of Sprint 1
(First Execution Stage)all tests were executed, but after completing Sprint 2 (Second Execution
Stage) only new functionality tests are executed. So to make sure that new features dont break
the old ones, regresion tests are carried out.
Note: SDLC Artefact - their is no standard template required for this. Agile is about being
adaptive, its upto you how you want to do it. As along as it is created in some form and
visible to all the team members its fine
Closing
This is where the projcet is closed after getting the sign off from custoner and warranty time
finishes. At this stage prouct goes in production environment and if support is in place than
support group enhances and maintains it.
Note: Items in yellow are not artefacts, they represent the process which takes place during
this stage. Artefacts are the outcomes from these process. Artefacts marked as Mandatorty are
required from project management perspective. They are required under Prince 2 Governance
Framework, they are not SDLC deliverables. Item in orange is a Gate for Prince 2.
• Artefacts
Lessons Learned
End Project Report
Artefacts
Lessons Learned
It is a repository of any lessons learned during the project that can be usefully applied to other

16. projects. The Lessons Learned Log is formally written up into the Lessons Learned Report at
project closure. The data in the report will be used by Corporate Program Management in order
to refine, change and improve the standards.
This is a mandatory artefact produced by PMO.
End Project Report
To report on how well the project has performed against its Project Initiation Document (PID),
including the original planned cost, schedule and tolerances, the Business Case and final version
of the Project Plan.
This is a mandatory artefact produced by PMO.
Post Production
Note: Items in yellow are not artefacts, they represent the process which takes place during
this stage. Artefacts are the outcomes from these process.
Artefcats
No artefacts are required for this stage.