Softxpert Scrum Process

Introduction to our process

Presented By:
Rafik Mclad
Quality assurance department.
Client centric
Customer-centric is an approach to doing
business that focuses on providing a
positive customer experience both at the
point of sale and after the sale in order to
drive profit and gain competitive
advantage.

It should be the leading concern of all the

team members to meet the customers
needs and solve customer satisfaction
Traditional waterfall
The waterfall model is a sequential design process in which progress is seen as
flowing steadily downwards (like a waterfall) through the phases of
Requirements definition, Design, Implementation, Testing, Deployment
and maintenance.
12 Principles of Agile
Communication problem
Early delivery
Over Engineering
One time Big Delivery
Multiple deliveries
Waterfall Agile

Predictive, sequential and planning Adaptive and iterative

oriented.

Less responding to change. Continually responding to change.

One large release of software. Incremental release of working software

Interactions with the business users to Interaction with customers, requirement

gather requirements happens in the early updates, frequent re-planning are ongoing
phase and requirements cannot be in each development period.
changed easily later on during next phases.

Work is document Oriented and document Minimal documentation upfront and only as
driven as every phase transition is much as required
documented and signed off.
Types of Agile
1. Scrum
2. Kanban
3. XP
4. Lean
5. Crystal
6. DSDM (Dynamic systems
development method)
7. FDD (Feature Driven
Development)
8. ASD(Adaptive software
development)
Example : Kanban Vs Scrum
Below is a comparison between the 2 most known agile methodologies.
Kanban: WIP Limits and Visualization
● Work is simply listed in a constantly
refined and reordered (according to
priority ) backlog list of tasks.(the to do
list)
● Team members once finish the task in
hand they pull another from the top of
the list (the highest priority).
● Releasing the work may occur every
time an increment form an MVP.
Kanban: WIP Limits and Visualization
● In Kanban, limited WIP and visualization are the main constraints. WIP can be limited in many different ways, but
the most common is to cap the amount of work in any given state. A maximum of five stories might be permitted
“In Progress,” or a maximum of three in “Test.” The WIP constraint in Kanban focuses the team on flow, and not on
time.
● Rather than up-front estimates of size and complexity, Kanban uses Service Level Agreements (SLAs) based on
historical cycle time. These become a constraint that encourages focus. Note that the SLA is not an estimate; it is a
prediction based on past performance. SLAs operate on each and every individual item in a Kanban system,
allowing a continual flow; work is not backed up into timeboxed iterations as in Scrum.
● Kanban also uses a prioritization buffer, called a Ready Queue. This short backlog contains items that are ready to
be worked on, but are not yet in progress. Teams and their Product Owners are free to alter the prioritization of
items in the Ready Queue at any time, giving them flexibility to rapidly adjust based on new information.
● Although there are no specific ceremonies in Kanban, it is customary to employ daily standups, regular grooming
sessions, and demonstrations of new functionality.
Scrum: Time boxed and cermonized
● Work is planned into releases that
is performed through iterations of
sprints with fixed time
● Releasing the work happens at the
end of the release after all the
work in scope is completed
through the last sprint.
Scrum: Time boxed and cermonized
● In Scrum, the most important constraint is the time boxed iteration, or Sprint, and the regular cadence of ceremonies.
The Sprint limits WIP through the creation of a Sprint Backlog. This backlog is usually estimated in story points and
sized based on past performance. If the team has a consistent velocity (e.g., 30 points per Sprint), capacity planning
starts with that number and adjusts it based on circumstances.
● The Sprint Planning ceremony ensures agreement on the content of the Sprint Backlog and its size. During the
iteration, the backlog serves as a prioritization buffer. Outside of that buffer, the Product Owner can make as many
reprioritization decisions as necessary, but the Sprint Backlog should only be adjusted in rare circumstances, so that
the team can focus on delivering that Sprint’s Goal.
● The Sprint Goal is a clear expression of value, the focus for that Sprint. Daily standup meetings allow the team to
self-organize and determine how to progress towards the goal. The Sprint Review gives them—and their
stakeholders—feedback on whether that goal was met, and informs the objective of the next iteration.
Roles of scrum?

● Development team
(including Developers front
end and back end, Designers
and testers.
● Scrum Master manages all
aspects of the Scrum
Team’s process.
● Product Owner who
manages and is responsible
for the Product Backlog.
Scrum events
1-Release planning
What happens in it:
● PO explains the scope of the Release.
● Team investigate the dependencies of the work in this release.
● PO answers teams questions about the release
● Team sizes the stories after decomposing any story that proves to be larger
than suitable (an epic or a feature)
● PO and scrum master agrees upon the definition of done policy for this
release.
● PO generates the Release plane based on the sizing and utilization plan of the
team.
2- Sprint planning
What happens in it:
● PO introduces the selected list of stories to be covered during the upcoming
sprint based on Customer priorities.
● Team starts decomposing the stories into tasks.
● Scrum Master assigns the tasks to team members.
● Team members set their estimations for each task.
● Note: estimates must be stated on the task management system (which is in
our case TFS) for tracking and enhancement reasons.
3- Standup meetings
What happens in it:
● All team members meet for a short status meeting (made standing up to
encourage finishing fast).
● Each team member goes over what he did yesterday , what he is planning to
do today and if there is any blocking or questions.
● Scrum master and/or PO arrange fixing any blocking and answering any
question (Note: that might be by scheduling another closed meeting to avoid
breaking the scope of the standup and wasting the other team members
time.)
● Note: the task management system must be updated by all team members
before every standup meeting since it is used to guide the standup.
4-Sprint review (demo)
Sprint review:
● Team should have reviewed all the completed stories against the DOD.
● Team Delivers the Integrated increment to the PO through a demo
demonstrating the work completed.

Sprint Demo:
● PO shows the stakeholders the output increment through a demo.
● PO Takes the feedback from the stakeholders if any.
● Sometimes the development team presents the demo themselves to the
customer.
5- Sprint Retrospective
What happens in it:
● Team meet to discuss 3 main titles:
○ What positive improvement happened during this sprint.
○ What mistakes we did during last sprint.
○ What we can do better in the next sprint.
● Discussion must be based on facts and incidents not emotions and feelings.
● Documents that play a major role in this meeting as an input are:
○ Customer Satisfaction form (can be presented through the PO).
○ Estimation variance report: to discuss and plan enhancements of over and under estimation incidents.
○ Testing Report: to discuss the types and amount of bugs produced by the team and plan enhancements for
each team member.
● At the end of this meeting team comes up with action items to be followed in future
sprints , each item should:
○ Have an owner.
○ Preferably recorded as a task for its owner.
○ Action items must Be SMART(specific, measurable, attainable, realistic and timely)
Iterations
● A Release is a period of time that is planned to cover a certain scope of work.
● Each Release consists of 1 or more Sprints of equal duration.
● Sprints must be in equal interval except 0 sprint and stabilization sprint.
● Sprint 0 is mostly used for spikes and investigation in order to build a more educated release
plan.(optional and not often)
● Day 0 or first day of a sprint is where the developers do their spikes to put their actual estimates
for their tasks in this sprint.
● Stabilization is a sprint that is at the end of release , its purpose is mainly to perform fixes of
smoke testing bugs and client feedback (optional and not often)
● Each Sprint is supposed to produce an increment which is an accumulation of the work done
during this sprint and the work done during the previous sprints.
● The increment resulting from the last sprint of the release should be in a shape of a MVP
(minimum viable product) which is a usable package for the client to try out live providing ROI.
● The sprint process is repeated over and over to cover the Release scope plus the feedback from
the client over the previous sprints.
Scrum artifacts
● Product Backlog : the list of all the upcoming stories
● Sprint Backlog :the list of selected stories to be covered in this sprint.
● Sprint Burndown Chart (optional) : a graphic representation that shows the rate at which work
is completed and how much work remains in the current sprint.
● Increment : It is the accumulated integration of the work completed during the last finished
sprint and the work completed during the previous sprints and it is the subject for a sprint
review and sprint demo.
● Product or release burnup chart (optional) :a graphic representation of the amount of work in
this release, any update (increase or decrease) in this amount, work progress over this scope
and can predict from it when it is expected to finish the release.
Scrum Documents
● DOD (definition of done) document: Agreed upon by the team before the release starts and can’t be
changed during the release time It contains the conditions that must apply in order to consider any
story as Done, it is used as a reference to compare each story before stating it is complete.
● Release Plan: Prepared by the PO after the release planning session, It is a guideline that reflects
expectations about which features will be implemented and when they are completed. It also serves
as a base to monitor progress within the project.
● Testing report: Provided by the teams testers the Testing report is a statistical report that shows the
numbers and severity of the bugs found and compares them with the numbers of test cases run,
also it presents the owners of these bugs, it is one of the major inputs of the retrospective
meetings as a facts list to be discussed.
● Retrospective meeting report: Developed by the whole team during the retrospective meeting, the
retrospective report is a record (supported with incidents) of positive things that was done during
the sprint, mistakes that were done and things that would have helped if were done and finally an
action list to be applied during the next sprint to insure the constant enhancement of the teams
performance.
What are the backlog items

Backlog : which is the list of all work items

needed to be done prioritized by urgency.

Sprint Backlog: Which is the list of work items

that will be covered during this sprint.

Work Item types:

User story details
Our work is basically focused and driven from user stories so we will focus on the a consistency of it.

A user story is clear and direct but by itself doesn’t carry enough information to do the development and testing work so it
needs more details.

Some of the stories are technical stories suggested by the team and some other stories are scenarios that the testers
came up with that were not considered while writing the stories, both are discussed with the PO and approved and
included in the plan.

Example:
User story: As an account owner I want to be able to login to my account so I can access my information.
Acceptance criteria:
● Account must be active.
● Credentials must be correct.
● Check warning message appears in case of account in active
● Check warning message appears in case credentials are not correct.
User story details
over TFS
Here is how the User story looks on TFS, you can see that the story statment is in the description box while the
acceptance criteria in its place on the right , you can also see the Effort field where the Story size is supposed to go.
Tasks
In order to perform the work of the user story it should be divided into more
detailed smaller in size tasks like in the example below:
 Task details
Validate the account credentials entered by the user and send to inbox screen if
accepted or show the the standard message in case of incorrect credentials or
closed account.
Scrum project Example
Menna is assigned as the Scrum Product Owner of a new software development project. She starts to
break-down the high-level requirements into smaller-grained user stories. With this list she then calls for
the first Sprint Planning meeting.
Sprint 1 - Day 0
During the Sprint Planning meeting Menna presents the Scrum Product Backlog items from the highest
priority to the lowest. The team clarifies open questions and for each item the team discusses if they have
enough capacity, the required know-how and if everything else needed is available. After this discussion
they commit to complete the stories 1,2,3,6,7 and 8 until the end of this sprint. The items 4 and 5 cannot
be committed in this sprint, as some technical infrastructure is not yet in place.

The whole team discuss and agrees upon the Definition of done policy.

After the Sprint Planning meeting Sally- the Scrum Master of the team - calls the team to define the details
of how the committed items are going to be implemented and in which order (according to dependencies)
to be able to meet the deadline. The resulting tasks are written down on the Task management system
and time estimations are added for each task by its owner. Now everyone of the Scrum Team selects a
task to work on.

Now Menna the PO can inform the customer the scope off this sprint and sets a date for the demo to
review the work completed at the end of the sprint.
Sprint 1 - Day 1
In the morning the whole team gets together for their Daily Scrum Meeting. Everyone gives a
short statement what has been achieved so far, updates the estimation of remaining hours
on the cards of the Sprint Task board, tells what he or she is planning to do today and tells if
there are any impediments that hinders him to continue his work. Today one of the team
members tells that he has problems because he needs a new license for one of the software
tools he is using. Sally checks if other team members have the same problem and says that
she'll take care of that after the meeting. After 15 minutes everyone goes back to work.

After the meeting Sally updates the Sprint Burndown. Then she calls the software vendor of
the tool, orders licenses and forwards them to the people that need them.
Sprint 1 - Day 10
This is the final day of the first Sprint and Sally –Scrum Master- has invited the team for the Sprint Review
Meeting. The team has prepared a machine with the current software implementation. Menna –Scrum Product
Owner- sits in front of the machine and checks if the implementation meets her expectations and if the features
are documented as required. At the end of the Review Session she concludes:

● Stories 1,2,6 and 7 are finished as expected.

● Story 3 couldn't be finished in time and was not presented at all. (Scrum Master reported this earlier to the
PO as she should)
● Story 8 has some points that have to be refactored

In the afternoon the team gets together for the Sprint Retrospective Meeting and discusses what went well during
the sprint and what could be improved. One of the feedback is that the team has the belief that they do not know
enough about the overall system UX associated with certain occasions to support that believe. Sally takes the task
to invite the Designer to give a more detailed introduction. Other actions are listed and assigned to related owners
to be followed in upcoming sprints.
Sprint 2 - Day 0
After meeting the customer and presenting the work through a demo session
Menna –Scrum Product Owner- adds new items to the Scrum Product Backlog
based on her recent customer meetings. She also communicates the customer
impression and level of satisfaction to the team.

Moreover, she adds additional items for the re-factoring of story 8. Menna then
invites the team for the Sprint Planning Meeting for Sprint 2. The team discusses
and commits to stories with the guidance of Sally –Scrum Master- and the second
Sprint begins.
TFS TFS (Team Foundation Server) is our current Task management system, We use it to manage the following:

● Backlog items management and history 1. Iterations and timeline.

tracking. a. Create Releases.
○ Creating the items in the backlog list. b. Create sprints under releases.
○ Allocating items into a sprint. c. Following up on sprint burndown chart.
○ Assigning items. 2. Alerts:
○ Filling in items information. a. Generate alerts on certain events.
■ Description. 3. Query :
■ Size. a. Search and filter work items.
■ Estimation.
■ History and updates of each task.
○ Tracking Item progress.
■ Status. Note: Link to Detailed TFS presentation
■ Actual effort.
■ Spike results.
 QA Audit FAQ
What is noncompliance?

Noncompliance is a record of breaking the regulations of the process agreed upon.

How can you know when you get a noncompliance assigned to you?

You can either create a TFS/Azure alert that triggers and sends you an email every time a noncompliance is assigned to you , or you
can simply create a query that shows any noncompliance assigned to you and check it periodically.

How to deal with a noncompliance?

· Resolve it before its due date and change its status to “Resolved”.

· Write any needed clarification in the comment section.

\
What are the QA Checks and how are they recorded as noncompliance tasks?

In the following google sheet link you will find a list of all the Quality assurance Audit checks each with its owner to be, expected due
date and severity.

https://docs.google.com/spreadsheets/d/1HIRSaKUnCgcNDL_TaHKMjTLn2CZ1-ofyOFAIcU5xGgA/edit?usp=sharing