quality manual project process
TRANSCRIPT
-
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
https://docs.google.com/a/codeenigma.com/document/d/1ijKs040CMJck0Genc4333zF1bbHF4sPp-zzy2Lp6VAg/edit# -
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
https://drive.google.com/a/codeenigma.com/?tab=mo#folders/0Bwapm9oHSGzibGtpWnhUVVdYZGc -
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
https://docs.google.com/a/codeenigma.com/document/d/1BL5hkD2V3uYBurF9Z4LWyUnw8YaNULvCOK3poQP9mGw/edithttps://docs.google.com/a/codeenigma.com/document/d/1Dxy47d_2224jFuHwQTwa7cpsE9gK_O00VzqegHRfu30/edithttps://docs.google.com/a/codeenigma.com/document/d/1Dxy47d_2224jFuHwQTwa7cpsE9gK_O00VzqegHRfu30/edithttps://docs.google.com/a/codeenigma.com/document/d/1Dxy47d_2224jFuHwQTwa7cpsE9gK_O00VzqegHRfu30/edithttps://docs.google.com/a/codeenigma.com/spreadsheet/ccc?key=0Av7Qb2rUXtnBdC1BRjUzZVRYYnBjQ05OZkkyNk82UWc#gid=0https://docs.google.com/a/codeenigma.com/spreadsheet/ccc?key=0Av7Qb2rUXtnBdC1BRjUzZVRYYnBjQ05OZkkyNk82UWc#gid=0https://docs.google.com/a/codeenigma.com/document/d/1BL5hkD2V3uYBurF9Z4LWyUnw8YaNULvCOK3poQP9mGw/edit -
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
http://www.google.com/url?q=http%3A%2F%2Fredmine.codeenigma.com%2F&sa=D&sntz=1&usg=AFQjCNHnuEsM-hTm-8JAYpARxPSxHOrVYA -
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
http://www.google.com/url?q=http%3A%2F%2Fjenkins.codeenigma.com%3A9090%2Fxplanner-plus%2F&sa=D&sntz=1&usg=AFQjCNGo6f3CLfOrqdfR_RBfxvLDL35dEQhttp://www.google.com/url?q=http%3A%2F%2Fredmine.codeenigma.com%2F&sa=D&sntz=1&usg=AFQjCNHnuEsM-hTm-8JAYpARxPSxHOrVYA -
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
http://www.google.com/url?q=http%3A%2F%2Fjenkins.codeenigma.com%3A9090%2Fxplanner-plus%2F&sa=D&sntz=1&usg=AFQjCNGo6f3CLfOrqdfR_RBfxvLDL35dEQhttp://www.google.com/url?q=http%3A%2F%2Fredmine.codeenigma.com%2F&sa=D&sntz=1&usg=AFQjCNHnuEsM-hTm-8JAYpARxPSxHOrVYA -
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
http://www.google.com/url?q=https%3A%2F%2Fgit.codeenigma.com%2F&sa=D&sntz=1&usg=AFQjCNFNDuiA4lRGEyOhqpggug2WZKfk8Qhttp://www.google.com/url?q=http%3A%2F%2Fjenkins.codeenigma.com%3A9090%2Fxplanner-plus%2F&sa=D&sntz=1&usg=AFQjCNGo6f3CLfOrqdfR_RBfxvLDL35dEQhttp://www.google.com/url?q=http%3A%2F%2Fredmine.codeenigma.com%2F&sa=D&sntz=1&usg=AFQjCNHnuEsM-hTm-8JAYpARxPSxHOrVYA -
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
http://www.google.com/url?q=http%3A%2F%2Fredmine.codeenigma.com%2F&sa=D&sntz=1&usg=AFQjCNHnuEsM-hTm-8JAYpARxPSxHOrVYAhttp://www.google.com/url?q=http%3A%2F%2Fredmine.codeenigma.com%2F&sa=D&sntz=1&usg=AFQjCNHnuEsM-hTm-8JAYpARxPSxHOrVYAhttp://www.google.com/url?q=http%3A%2F%2Fbot.codeenigma.com%2Fbot%2Flog&sa=D&sntz=1&usg=AFQjCNFkaoI1dWpGhvJJZhrL32SorrDpWAhttp://www.google.com/url?q=http%3A%2F%2Fbot.codeenigma.com%2Fbot%2Flog&sa=D&sntz=1&usg=AFQjCNFkaoI1dWpGhvJJZhrL32SorrDpWAhttp://www.google.com/url?q=http%3A%2F%2Fbot.codeenigma.com%2Fbot%2Flog&sa=D&sntz=1&usg=AFQjCNFkaoI1dWpGhvJJZhrL32SorrDpWA -
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
mailto:[email protected] -
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
https://docs.google.com/a/codeenigma.com/?tab=mo#folders/0B3qYoCLY1jucWklPSWw2c01RN1Uhttps://docs.google.com/a/codeenigma.com/?tab=mo#folders/0B3qYoCLY1jucWklPSWw2c01RN1Uhttps://docs.google.com/a/codeenigma.com/?tab=mo#folders/0B3qYoCLY1jucWklPSWw2c01RN1Uhttps://docs.google.com/a/codeenigma.com/?tab=mo#folders/0B3qYoCLY1jucWklPSWw2c01RN1Uhttps://docs.google.com/a/codeenigma.com/?tab=mo#folders/0B3qYoCLY1jucWklPSWw2c01RN1Uhttps://docs.google.com/a/codeenigma.com/?tab=mo#folders/0B3qYoCLY1jucWklPSWw2c01RN1Uhttps://docs.google.com/a/codeenigma.com/?tab=mo#folders/0B3qYoCLY1jucWklPSWw2c01RN1Uhttps://docs.google.com/a/codeenigma.com/?tab=mo#folders/0B3qYoCLY1jucWklPSWw2c01RN1Uhttps://docs.google.com/a/codeenigma.com/?tab=mo#folders/0B3qYoCLY1jucWklPSWw2c01RN1Uhttps://docs.google.com/a/codeenigma.com/?tab=mo#folders/0B3qYoCLY1jucWklPSWw2c01RN1Uhttps://docs.google.com/a/codeenigma.com/?tab=mo#folders/0B3qYoCLY1jucWklPSWw2c01RN1Uhttps://docs.google.com/a/codeenigma.com/document/d/1BJvLwSImkqDsgq8ONalGs37tSGVmPp4gPonfqu2FGZY/edit -
8/9/2019 Quality Manual Project Process
20/20