Quality Manual Project Process

8/9/2019 Quality Manual Project Process

1/20

Quality Management System

Section 2: Project Process

ISO 9001:2008

1

8/9/2019 Quality Manual Project Process

2/20

Managing Projects

Code Enigma uses the Scrum method, one of the family of agile project management methodologies, to

manage its larger projects. For some smaller project we will not apply the full Scrum model and the project

management model for these smaller project is described here.

Scrum, indeed agile development, is ideally suited to projects where it is difficult to plan ahead for any

significant period into the future. For this reason it is great for ongoing software development, where the

goal is a moving target, the technology involved is in a state of continuous flux and, consequently, an

organisations understanding and use of different technologies is also under constant change. The primary

benefits of Scrum to Code Enigma and our clients are:

Fast time to market

Iterative deployment

Enhanced change management

Continually testing and improving the end product

Continually reviewing the project processes for that project and adopting change where necessary

Customer retains control of the finished product throughout the project

Business objectives remain the focus of development

Scrum as a method is fairly minimal but, combined with our own project and quality processes, it ensuresthat we impose the necessary controls on all projects to manage and measure their success.

By utilising the Scrum method we reduce the risk of projects not delivering what is expected by:

Providing regular demonstrations of the functionality as its developed

Allowing the customer to experience functionality early in the project

Only planning features we can finish and deliver

Making change easy by working in short bursts

Project Roles

There are five main roles in every project:

The Product Owner

This is a single person from the client, responsible for capturing the client requirements as user stories,

curating the backlog of user stories, defining a Minimum Viable Product (MVP) for initial launch (if

applicable) and ensuring the client business goals remain the focus of sprints, identifying the user stories

2

8/9/2019 Quality Manual Project Process

3/20

with the highest priority to the business. This role is the most critical to the success of the project and we

have processes in place to help organisations to pick a suitable Product Owner.

The Scrum Master

This role oversees the project, collects and manages metrics, ensures that Scrum practices are adhered to,

supports the Product Owner, engages the Project Mentor as required and helps remove any obstacles that

impede the development team. This role is the primary point of contact for the client Product Owner.

The Lead Developer

This is the member of the project team responsible for key technical decisions, solution architecture, code

quality, existence of tests and documentation and developer mentoring.

The Team

This is the design and development team responsible for the delivery of the sprints. Theyre a self-managed

team with no project manager, although the Lead Developer is responsible for ensuring they stick to the

defined project processes and the Scrum Master is responsible for recording their activity and assisting

them with any issues that arise.

Project Mentor

This role provides continuity from the sales process and provides a detailed handover of the project to the

team, Scrum Master and the Product Owner. The Project Mentor is also responsible for assisting the

Product Owner and ensuring they are effective in their role, taking over that role for short periods ifnecessary, ensuring communications are happening in a timely fashion.

The Project Mentor role is not specific to Scrum but was identified as a requirement by Code Enigma. Its

primary purpose is to maintain customer relationships, and support the Product Owner to function

effectively, and to monitor progress while the product is being developed. It is a birds-eye view of the

project and the clients business that keeps the two focussed on the same goals. There is a large amount of

cross-over here with the Product Owner, however we have identified there is sometimes a need to

duplicate this effort to reduce the risk of the project going off track and support the Product Owner.

Stakeholders

There is also a role on the periphery of Scrum, but important to identify and understand the Stakeholder.

While the Product Owner is the person who makes all decisions and communicates with the provider

team(s), Stakeholders are important in the process. These are people who are a part an organisation

engaged in the project in a client relationship for whom the project will have a direct impact. The Product

Owner should be in touch with his or her Stakeholders, listen to their requirements, balance their different

priorities, keep them informed and manage their expectation. Typical Stakeholders might be:

People responsible for the financing of the project

3

8/9/2019 Quality Manual Project Process

4/20

The client users of the resulting software

Managers whose resource might be affected by the project

Some types of Stakeholder should be avoided, for example:

Part-time, freelance or interim staff

Senior managers with no direct interest in the project

We refer later to the Primary Stakeholder. This is the person who is ultimately commercially responsible for

the success or failure of the project in the context of the organisation as a whole - it is not necessarily

someone who is operationally engaged on the project, for example, it could be a member of the Board of

Directors of a given client.

Project PhasesThere are six main phases or stages of projects that we have identified, for the purposes of our project

lifecycle:

1. After-sales

2. Onboarding

3. Backlog Management

4. Planning5. Construction

6. Project Closure

After-sales

Before the project can start Code Enigma must select a Project Mentor and that person must assist the

client organisation in selecting the Primary Stakeholder. Typically this will be someone in senior

management at the client organisation who is ultimately responsible for the success of the project and will

have to answer to the senior management for it.

Product Owner Selection

Once the Primary Stakeholder is appointed, they will need to select a Product Owner for the project. The

Product Owner must be selected rapidly at the start of the project and this person should not change for

the duration if at all possible. Because this is such a critical role, we also recommend Primary Stakeholder

familiarise themselves with the Product Owner Manual in this Quality Manual before making their choice.

Other Roles

Finally, the Project Mentor will also have to appoint a Scrum Master and Lead Developer for Code Enigma

4

8/9/2019 Quality Manual Project Process

5/20

to work on this project. Once these key roles have been placed, Onboarding may commence.

Onboarding

The onboarding process commences once it is clear that the client is committed to the project and starts

with a stakeholder introduction meeting.

The onboarding process uses an onboarding workshop to capture some of the information and key

behaviours the project needs people to engage with to be a success. Principal points are:

Communication Strategy

Communication written and verbal is key to the success of our projects. There is regular communication

between the client and Code Enigma that is scheduled into the project. Without that the Scrum process

would not be effective. Communication frameworks between Code Enigma and the Product Owner and

Code Enigma and the Stakeholders are agreed at the outset and carefully adhered to. This occurs as a part

of the onboarding workshop during the various meetings with Stakeholders and the Product Owner.

Documentation

Project documentation has a standard format and is normally stored in Google Drive. A project folder is

created for every project. References to specific documents are detailed throughout the Quality Manual.

Client access to documents stored in Google Drive can be managed on a per-project basis. We create an

open/shared directory into which we store all documents related to the project. Generally, documentation

that requires client access is stored in the Google Drive project directory.

The template for projects documentation is located here

Workshop Days

Client onboarding workshops are essential and obligatory. The agenda is as follows:

Day 1

Stakeholder introduction (all affected parties must attend, led by Project Mentor) 1 hour

Agile training (Product Owner must attend at a minimum, led by Project Mentor and/or Scrum

Master) 5 hours

Product Owner introduction (Product Owner must attend, led by Project Mentor) 1 hour

Day 2

Stakeholder interviews (every Stakeholder must attend in turn, led by Project Mentor) half hour

5

8/9/2019 Quality Manual Project Process

6/20

each

Risk Analysis meeting(Product Owner must attend, Stakeholders and Scrum Master encouraged to

attend, led by Project Mentor) 1 hour

Project Backlog meeting (Product Owner and Project Mentor must attend, led by Scrum Master)

3 hours

Project Kick-Off meeting (all affected parties must attend, led by Project Mentor) 1 hour

Each one of these meetings has a fixed and predefined agenda which can be viewed in your Google Drive

folders and is linked to from the meeting title. You can see the required deliverables and responsibilities

surrounding each of these meetings in the agenda items. The following sections of the Onboarding phase

documentation go into more detail on key aspects of the workshop and why they are important:

Risk Analysis

Risks are recorded in a Risk Register at the beginning of every project and the register is reviewed in every

Sprint Retrospective and at the start of every Sprint Planning meeting. A weekly risk register review may

also be scheduled for larger projects. Individual risks, where deemed necessary, have mitigation plans

recorded as Risk Response Plans, which are agreed between the Product Owner and the Project Mentor

and include information such as allocation of emergency budget, mitigation strategies, etc. This Risk

Register is created during the onboarding workshop, during the fixed agenda Risk Analysis meeting. It is

then reviewed frequently using the schedule agreed in the initial workshop meeting. For clarity, this

Register is for capturing risks specifically associated with the project from the perspective of Code Enigma.

It is expected clients maintain their own Risk Register for broader project risks they may encounter whichare specific to them.

Documented Specification

Managing projects using an Agile approach means that the project is not specified in its entirety at the

outset. Instead we define broadly the functionality the project will deliver using User Stories in a Product

Backlog, owned by the client Product Owner. The contract that is agreed at the outset of the project will

define a very basic outline of the project, loosely defining the Minimum Viable Product (MVP) the client

feels is necessary to launch. Using an Agile approach means that the client pays for development time

during which they control and direct the development of the product toward and usually past this MVP.

As we investigate the product functionality and approaches there will be some ad-hoc documentation

produced. This will be stored in the project file within Google Drive:

Client Name > Project Name > Technical Notes

Client Name > Project Name > Reference

Depending on the requirements, additional folders might be created in the directory.

6

8/9/2019 Quality Manual Project Process

7/20

Product Backlog Training

The purpose of the meeting to begin the Product Backlog is to provide training and guidance and begin the

Backlog Management phase. It is not possible to complete the Product Backlog in this session, but rather

the aim is to ensure the Product Owner understands the fundamentals of managing a Product Backlog. The

Product Backlog itself is covered in far more detail in the next section of this document regarding the

Backlog Planning phase of a project.

7

8/9/2019 Quality Manual Project Process

8/20

Summary

Overall flow and responsibility during the After-sales and Onboarding phases of a project are represented

by this diagram:

8

8/9/2019 Quality Manual Project Process

9/20

Backlog Management

While this is captured as a phase, in reality Backlog Management never stops. The Product Owner must

be continuously engaged in pruning, challenging, ordering, detailing and verifying the Product Backlog, so

that when the Scrum Master comes to sprint planning the top stories in the Product Backlog represent thehighest priorities to the client organisation andthey are sufficiently detailed so as to allow for planning to

go ahead.

Product Backlog

The project begins with the Product Backlog which is controlled by the Product Owner. The product

backlog is a list of user stories that define the products functionality from a user perspective. It is the

responsibility of the Product Owner to create and curate all aspects of these User Stories. The Product

Owner owns the Backlog.

As noted in the previous section, the beginnings of the Product Backlog is created in a 3 hour workshop

session with the Scrum Master and the Project Mentor, where the Product Owner learns how to create and

manage User Stories in the Backlog. It is then the responsibility of the Product Owner, with the support of

the Project Mentor if required, to continue after that workshop to complete and prepare the Product

Backlog in readiness for the first sprint planning session. The Project Mentor may assist the Product Owner

in capturing the required features in the correct format, but the Product Owner must be driving the

selection of features at all times.

If the Product Backlog is not in a ready state for sprint planning, sprints must be postponed.

A user story describes a specific piece of functionality from the point of view of the user. A well written user

story will describe who the user is, what theyre doing and what they expect the result to be, for example:

As a [ user ]

I want to [ achieve ]

So that [ outcome ]

There should be no technical assumption in a user story. Here is an example of a good user story:

9

8/9/2019 Quality Manual Project Process

10/20

As a content editor I want a page containing a list of stories in the admin area of the website, with the

ability to sort the stories by various criteria so that I can easily find content requiring editorial attention.

Each user story must include acceptance criteria a description of what is required and expected of the

story. This helps understanding of the story, removes ambiguity and provides a level of detail for the client

to write their own test cases. It is also essential for developer estimating when a sprint is planned, so stories

without acceptance criteria cannot be added to a sprint.

1. User with content editor status can navigate to page with list of stories

2. User can see status of story in order to identify those needing attention

3. User can change default order of listing to sort by title ascending / descending order

4. User can change default order of listing to sort by date ascending / descending order

5. User can change default order of listing to sort by author ascending /descending order

The Product Owner, by prioritising the User Stories in the backlog, is able to change what is developed. The

Product Owner is able to make changes to the overall Product Backlog throughout the life of the project

and include changes in future sprints. As the scope changes with the Product Backlog, these changes are

recorded by Code Enigma systems.

We require Product Owners to always have a sense of the Minimum Viable Product we mentioned earlier in

this document. This MVP represents the minimum acceptable features which must be completed before

the project can be considered complete from a launch perspective, although we counsel no project is

ever truly complete and Scrum is all about continuous improvement of both product and team.

A useful tool for prioritising stories for a sprint is to use the MoSCoW ranking:

Must

Should

Could

Wont (just yet)

Prioritising your User Stories in this way makes your MVP clear. All your musts are your MVP, everything

else is not, but you can organise your shoulds above your coulds when you curate your Product Backlog.

The User Stories that make up the Product Backlog must be captured in the Code Enigma project

management system, Redmine. We use this system because it is an online tool which ensures that its

readily available to any of our distributed team, regardless of their location, and our clients.

User Stories must have a clear Definition of Done. To that end, the Redmine User Stories include a

number of custom fields Code Enigma have created:

10

8/9/2019 Quality Manual Project Process

11/20

Checkbox to indicate if a feature is MVP, therefore absolutely essential to the delivery of a

successful project

Drop-down menu to select the MoSCoW priority (Must, Should, Could or Wont) for the story

Checkbox to indicate Blocked, therefore unable to enter a Sprint (see below)

Checkbox and text area for Acceptance criteria, where the Product Owner must capture the

detail of how the feature needs to function to be considered done

Text area for How to demo, where the Product Owner must note any specific requirements for

demonstrating this feature at sprint end to the Stakeholders

An example of a how to demo would be:

There is a user role that gives access to premium content. Show that when an anonymous user tries to

access content he gets an access denied message but when he logs in as a user with the relevant role, he

can now view the content.

Where clients prefer not to use the Code Enigma issue tracking system, it must still be kept up to date by

the Scrum Master, even if this is duplication of effort, to ensure Code Enigma retains good records

regardless of external recording mechanisms.

Each member of the team and the Product Owner has access to the backlog tool for their project. It is the

responsibility of the Product Owner to provide access to their chosen tool for managing the backlog to the

Scrum Master if they are not using the Code Enigma systems.

Sprint 0 / Sprint Scouting

If, once the Product Backlog is considered ready for Sprint Planning, there are large knowledge gaps

surrounding technology, possible multiple routes to take as a solution, etc. then a Sprint 0 is typically

planned. This is not a development sprint, this is an exercise in researching and rapid prototyping to ensure

the team are ready to go once the first development sprint is commissioned. Typical Sprint 0 candidates

might be:

Creating a proof-of-concept prototype to test an approach with Stakeholders Reading API documentation and testing functionality

Familiarisation with third-party products necessary for integration with the solution

Sometimes even later in the project process some degree of sprint scouting is necessary, which means if

we identify tasks against User Stories about which we know almost nothing, somebody must take the time

to further investigate those tasks before they can be planned into a development sprint with any kind of

accuracy. A typical approach to this is to essentially remove the Lead Developer from the live development

sprint and use the freed time to engage in sprint scouting, researching and testing approaches for tasks

to be planned in for the next sprint. This is essentially the same as Sprint 0, but it occurs once a project is in

progress, while Sprint 0 is specifically prior to project commencement and occurs while the Product Backlog

11

8/9/2019 Quality Manual Project Process

12/20

is being developed by the Product Owner.

In either case, the purpose is simple. Guessing of development estimates during Sprint Planning is strictly

forbidden, as planning is impossible if we guess - Sprint 0 and sprint scouting allow us to find out more

about items we would otherwise need to guess on prior to Sprint Planning occurring, so we can accuratelyestimate the development work during Sprint Planning.

12

8/9/2019 Quality Manual Project Process

13/20

Planning

Each project follows the Scrum framework. It is useful to review our interpretation of the process first:

13

8/9/2019 Quality Manual Project Process

14/20

Sprint Backlog

The Sprint Backlog contains the top items from the Product Backlog for inclusion in the current sprint. The

Product Owner is able to re-shape the product being developed before the start of each sprint by ensuring

the User Stories they wish to have tackled first are at the top of the Product Backlog. This enables them tocreate a product that remains fit for purpose, even if the scope and business need changes dramatically

during the project lifecycle. This process provides and encourages change rather than imposing unwieldy

change control procedures.

The Sprint Backlogs are always kept in Redmineand are duplicated in Xplannerfor the purposes of

capturing specific technical tasks against stories during Sprint Planning, gathering project metrics and

recording time on tasks for meaningful retrospective reporting. The metrics gathering and time recording is

the responsibility of the Scrum Master.

Sprint Planning

Projects deliver iteratively and these iterations are termed Sprints. Normally sprints will be three weeks

duration and contain 12 days of developer time. In each day there are 5 hours of available intense

development time per developer for work on Stories and Tasks. The sprints are planned by the Product

Owner and The Team, with the Scrum Master acting as chair. Before Sprint Planning begins, the Product

Owner must be sure the Product Backlog is correctly ordered with the highest priority User Stories first.

A sprint planning meeting will be held in two separate parts. In the first (a 2 hour time-boxed meeting), the

issue and risk registers are reviewed and with the entire team. Next the Scrum Master selects the User

Stories from the top of the Product Backlog and places them into the next Sprint Backlog, retaining their

priority, which should already have been set according to business priority by the Product Owner prior to

planning.

Referring back to the MoSCoW acronym used in the Product Backlog section, it is recommended, and

Product Owners will be encouraged, to order the Product Backlog so that any one Sprint Backlog has

approximately 60% must features and the rest made up of should and could features. The reason for

this is simple expectation management. If every feature is a must and anything goes wrong, the sprint will

not deliver and the Stakeholders will be disappointed. Ensuring we do not overload the sprint plan with

musts helps us manage expectation and always deliver the critical functionality, even if surprises have

taken us off track during development.

14

8/9/2019 Quality Manual Project Process

15/20

At the same time, a Sprint Backlog should equally never be made entirely of should and could User

Stories when there are existing must stories. In this case, key essential functionality is not ready to be

developed, but it is being ignored and the Development Team are burning development time on

non-essential features, which is always a mistake. If there is not a decent number of must User Storiesready to be planned, Sprint Planning cannot take place. It is possible to re-categorise MoSCoW priorities at

the beginning of each sprint provided that we recognise that these priorities only relate to the current

sprint and do not change the definition of the MVP established at the outset of the project.

In the second part of sprint planning, the Development Team works together to define the technical

approach to each story selected for the sprint together with estimates for each story and creates a

development task list. If the sprint is considered to be over-allocated or under-allocated the team will then

liaise with the Product Owner to accept more or remove some stories from the Sprint Backlog.

The Scrum Master divides the number of hours available for technical planning by the number of stories to

be estimated, to strictly time box the estimating process and ensure time is not wasted discussing stories

that are simply not ready for development.

It is fundamental no guessing is done in the second half of the Sprint Planning. If there is not enough detail

to estimate a User Story effectively, it cannot enter the Sprint, so it must either be pushed back to the

Product Backlog or, if it is essential or there are not enough User Stories ready for a sprint to go ahead, the

planning must be cancelled and the Sprint delayed until it can be accurately estimated.

Details of the user stories selected for a sprint during the planning session are recorded in both Redmine

and Xplanner. It is the responsibility of the Scrum Master to record the development tasks accurately.

Redmine contains an overview, discussion and notes on a story level, Xplanner is used purely for detailed

capture of estimates and time tracking.

It is essential the Product Owner is actively engaged in Sprint Planning, particularly with a view to ensuring

the Stories added into the Sprint will allow for the demonstration the Product Owner wishes to see at the

end of the Sprint. At this point the Product Owner needs to define how they would wish the defined

Stories to be demonstrated, if there are any special requirements, so necessary sub-tasks to achieve the

required demonstration can be captured.

15

8/9/2019 Quality Manual Project Process

16/20

Construction

Once the planned sprint begins, the Development Team select user stories from the Sprint Backlog, develop

these and test them according to the description in the user story. Each member of the Development Team

is responsible for selecting, with help from their peers, which User Stories they intend to take.

Progress should be reported to the client by updating the sprint backlog in Redmine(for a high level view)

and also noting the progress towards actual stories burned and tasks completed in Xplanner(for detailed

analysis of progress).

The code being written during the development phase is controlled by Gitorious, the Code Enigma version

control system. This system enables developers to produce code in a separate fork before being merged

into a shared code repository, where the code is reviewed by the lead developer (or another teamdeveloper, if the code was written by the lead developer) before being pushed to the staging environment.

The Scrum Master will ensure the functionality is being tested in the staging environment on completion

and, assuming they are happy the code has passed the functional test, the story will be assigned to the

client tester (often the Product Owner, but not always) in Redmine so they can verify the test is passed.

Nothing is pushed to a live environment until the client has passed the stories.

Gitorious can be found at https://git.codeenigma.com

Stand-Up Scrum

The stand-up scrum meeting is a daily meeting, time-boxed to 15 minutes, during which each member of

The Team describes the following:

Yesterday I

Today I will

My blockers are

Anyone may attend the meeting, and Product Owners are encouraged to do so, but the format is fast and

long discussion is discouraged. The Scrum Master chairs the meeting and in that persons absence the Lead

Developer takes over.

The purpose of the meeting is to provide a status update to The Team, encourage knowledge transfer and

communication, and make sure everyone knows what they are doing for the day.

The daily scrum is also the time to highlight a blocker, or impediment, that affects progress. This can be an

existing risk or issue or a new issue or risk that needs to be logged. If anything is identified as a blocker then

the Scrum Master is responsible for recording and resolving that issue outside of the scrum meeting.

16

8/9/2019 Quality Manual Project Process

17/20

Those projects whose scrums take place in IRC have details recorded in the CE Bot Log. Whether written or

verbal, any issues or risks raised in the scrum are entered into the Redmine issue tracker and/or the project

risk register spreadsheet within the project directory in Google Drive. This is the responsibility of the Scrum

Master. The Scrum Master is also responsible for keeping a Scrum Diary for each scrum so there is a rollingrecord of the work that was done every day in a written format - this is sometimes easier to digest than

tickets in management systems.

User Acceptance Testing (UAT) & Non Conformities

UAT is the functional testing of the product by the client. The purpose of this is to check that the stories

which have been developed meet the acceptance criteria identified by the Product Owner and to capture

any non-conformity. To maintain project velocity and avoid an extended bug fixing phase at the end of a

project, UAT should be continuous during sprints and not a separate stage of the project. As such,

functional testing is built into our sprint tasks.

When a story is completed by a developer, he will update the test plan with the necessary information to

be able to perform testing. Then the developer marks the story as Ready to test in order for it to be

tested by Code Enigma (usually the Scrum Master) before being passed to the client for testing. These step

helps us identify any obvious errors and ensures that what is passed to the client is of the highest quality.

The updated test plans also ensure both internal as well as external testers have all needed information,

saving them time in not having to find user story background information on where to test the

functionality.

The process of passing the user story from developer to Code Enigma tester and then onto the client, and

dealing with feedback is done via Redmine. This provides us with:

Fully described the user story and acceptance criteria including links to Google Documents (or

attachments) where necessary, tracked and recorded

Workflow the ability to pass stories/bugs from developer to tester to client and back to developer

if necessary

The ability to search and filter stories to identify those in various states (open, assigned, testing,

closed, etc.)

The ability to provide feedback (for testing and clarification)

Whenever a bug (non-conformity) is found in testing, the tester will provide details of the bug (how it was

created, error messages, role being used) and assign the story back to the Product Backlog. This ensures

that the Story is entered back into the development cycle to be redeveloped and tested again at the nextavailable opportunity. Not until the acceptance criteria, as originally defined by the Product Owner, are met

under testing will the code be considered complete and the story marked as done.

17

8/9/2019 Quality Manual Project Process

18/20

A bug is non-conformity that must be captured by the process, fed back into the cycle and remain there

until it is considered passed.

Sprint Demonstration

On the final day of each sprint the Lead Developer demonstrates what was developed during the sprint to

the Product Owner and the Stakeholders. There is an initial practice demonstration, given to the Scrum

Master and the Project Mentor, where they will ensure any special demonstration requirements requested

by the Product Owner have been met. After that demonstration, the live Demonstration is given to the

Product Owner and Stakeholders.

This process provides the client with the means to test the new functionality, to demonstrate it to their

team and to get feedback from a wider audience. This feedback can then be fed into the backlog with aview to implementing it in a later sprint.

The Product Owner has the opportunity to specify demonstration technique, if required, prior to Sprint

Planning. If no preference is specified, the Lead Developer is briefed to demonstrate the functionality of

each User Story completed as succinctly as possible, demonstrating it has met the Acceptance Criteria

specified in Redmine.

Feedback for inclusion in the project is controlled by the Product Owner and recorded in the Product

Backlog.

Sprint Retrospective

A sprint retrospective serves to provide the developers, the Scrum Master and the Project Mentor with the

opportunity to look at how they approached a project and to look at ways in which they can improve in

future sprints and other projects. The retrospective can look at specifics for a given project and at general

development processes. Notes from the retrospective are held centrally and if anything is considered for

the attention of the client, this will be communicated at the client at the client sprint review.

The format of the retrospectives follows a pre-defined agenda. That is:

Mad/Sad/Glad - a statement by everyone on the project team on what made them mad about

the sprint, what made them sad and what made them glad, to capture emotional response.

A review of Sprint progress and task disposition in Xplanner to look for learning points.

A review of accuracy of task estimating in sprint planning in Xplanner to look for learning points.

It is the responsibility of the Scrum Master to raise any required changes to process or this Quality Manualwhich might arise from the Sprint Retrospective, by capturing the minutes in the provided meeting

template and raising a ticket via [email protected].

18

8/9/2019 Quality Manual Project Process

19/20

The sprint retrospective is recorded and monitored in the CodeEnigma-Sprint-Retrospectives document

located in Google Docs. Individual retrospective documents are also stored in the individual project folders.

Client Sprint Review

Following the internal sprint retrospective, a Client Sprint Review will be held between the Scrum Master,

the Lead Developer and the Product Owner. The meeting will be using the Sprint Review template

document as a guidance of the agenda.

Sprint Closure

Once a Sprint is finished, after the Demonstration and Retrospective, the Sprint is closed in Xplanner. All

remaining tasks are returned to the Product Backlog for future planning and the process begins again.

Stories that were not successfully tested against the Acceptance Criteria and demonstrated at Sprint endare not considered finished, regardless of how close to completion they are, and must be returned to the

Product Backlog.

Project Closure

The project is complete after the final MVP story has been demonstrated and passed the acceptance

criteria defined by the Product Owner. Once this happens, the Project Mentor or Scrum Master meets with

the client to discuss the entire project, whats been achieved, to understand the clients satisfaction and to

identify any changes that we need to adopt in order to better service our clients.

The End of Project Assessment template and completed documents can be found in:

Google Docs > Codeenigma Docs > Internal Projects > ISO9001 > End of Project Assessment

Completed assessments are stored in this folder as:

assessment date-client name-project name

Of course web projects are never done, so once the MVP is launched, and assuming the client wishes tocontinue, the next sprint is planned for whenever the client is ready and deems it necessary work

re-commences at that point.

19

8/9/2019 Quality Manual Project Process

20/20