SQM - Saba Quality Methodology

SOP-SDL-03-02, SDLC

Date Last Modified: February 03, 2014

Date Published: February 06, 2014

Author: Matt Ready

Status: Published

PROPRIETARY AND CONFIDENTIAL TO SABA

FOR INTERNAL USE ONLY

SQM Page 1 of 10
SQM - Saba Quality Methodology

Table of Contents
1 SOP Objective ................................................................................................................................. 3
2 SOP (Process) Description .............................................................................................................. 3
2.1 Definition of Release Types Delivered ...................................................................................... 3
2.2 Product and Release Backlogs ................................................................................................. 4
2.3 Development and Stabilization Sprints ...................................................................................... 5
2.4 Checkpoint, Program, and Scrum Meetings .............................................................................. 6
2.5 Sprint Review............................................................................................................................ 6
2.6 Product GA Readiness ............................................................................................................. 6
2.7 Release Postmortem ................................................................................................................ 8
3 SOP Exceptions .............................................................................................................................. 9
4 SOP Change Log .......................................................................................................................... 10
5 SOP Sign-Off ................................................................................................................................ 10

Page 2 of 10 Version changed on: Thursday, February 06, 2014

SQM - Saba Quality Methodology

1 SOP Objective

This document describes Saba’s overall Software Development Life Cycle (SDLC).

2 SOP (Process) Description

Saba is practicing a modified agile framework. The high-level phases within the release cycles
are the following:

Figure 1 – Please note number of planned sprints can change based on length of release cycle

2.1 Definition of Release Types Delivered

Product Release: Large product release delivered within 3-6 months, as determined by
business and market needs, that include new features, major product enhancements and
defect resolutions. Product Releases are cumulative of all previous product ion deployed
changes.

Maintenance Release: Minor product release delivered within 1-3 months, as determined by
business and market needs that primarily includes defect resolutions and may also include

Version changed on: Thursday, February 06, 2014 Page 3 of 10

SQM - Saba Quality Methodology

minor product enhancements. Maintenance Releases are cumulative of all previous production
deployed changes.

HotFix & Patch Releases: Single or cumulative defect resolutions delivered as required by
business and market needs, that include only defect resolutions and will not include any
product enhancements. HotFix and Patch Releases may be cumulative of all previous
production deployed changes depending on the type of Saba product platform.

2.2 Product and Release Backlogs

The Product Backlog is groomed continuously with Engineering leads, Product Managers
(PMs), and Quality Engineering. This can be facilitated by the Project team members or
member of the Program Management Office (PMO) (Figure 1 – Design Sprint).

 PM presents the Stories in the backlog that are candidates for the Project and creates
the Release Backlog. The Project team uses this time to thoroughly understand the
requirement requests and uses this as input into sizing estimates. If a requirement is too
large for a single sprint, the PM breaks the story into smaller, more manageable
deliveries. Items that require a large amount of additional definition are called out and
set aside for future consideration.

 Teams assess effort using various estimation techniques and commit stories to the
Project by “Scheduling” the stories to a sprint within the release management system of
record (JIRA).

 The output is to have a fully defined and groomed Release Backlog prior to Sprint 1 for
each Project as depicted in Figure 1.

Project Kick-off

Once the stories have been defined, groomed, and committed for the Project, PMO schedules
a Project kick-off as an official start to the development phase and provides a big picture view
to Project stakeholders.

 PMO facilitates the meeting

 30 minute meeting from PMs to the cross-functional release teams

Page 4 of 10 Version changed on: Thursday, February 06, 2014

SQM - Saba Quality Methodology

 Overview of the high-level themes/scope “Feature Bullets”

 Initial future planning begins for marketing launch activities, legal, pricing

Figure 2 presents a more detailed view into project activities during the SDLC.

Figure 2 – Please note number of planned sprints can change based on length of release cycle

2.3 Development and Stabilization Sprints

The development phase of the SDLC is broken down into Development and Stabilization
sprints. Sprint duration can range 1-4 weeks depending on release scheduling requirements.
After each sprint Engineering leads conduct a Sprint review of the completed Epics/Stories,
see SOP-DEV-03-02, Story Reviews.

 Completed Epics/Stories: Epics/Stories completed in the sprint are moved to Quality

Engineering for initial verification and included as part of the sprint review. The

Version changed on: Thursday, February 06, 2014 Page 5 of 10

SQM - Saba Quality Methodology

completion of Epics/Stories is captured within the epic/story tracking system of record

(JIRA).
 Incomplete Epics/Stories: If an Epic/Story that was originally scheduled for the sprint
is not completed by the sprint end date, the Epic/Story is rescheduled to a future sprint
or Project. The rescheduling is captured within the epic/story tracking system of record
(JIRA).
 Reopened Epics/Stories: Epics/Stories that are reopened due to failed test cases or
inadequate acceptance criteria are rescheduled to a future sprint or Project. The
rescheduling is captured within the Epic/Story tracking system of record (JIRA).

For testing activities during each Project, please refer to SOP-QE-04-02, Product Testing

2.4 Checkpoint, Program, and Scrum Meetings

As needed Engineering leads conduct daily Scrum meetings in their local time zones. At a
minimum, all team members must attend or send a proxy for the weekly checkpoint and
program review meetings. The team, by component/product area, reviews the stories
assigned to the sprint, current testing progress, and critical defects that are to be planned
for resolution during the remainder of Project.

2.5 Sprint Review

After each sprint Engineering leads conduct a Sprint review of the completed Epics/Stories,
see SOP-DEV-03-02, Story Reviews

2.6 Product GA Readiness

In order to facilitate a holistic release methodology, PMO leads a number of integrated release
readiness activities for cross-functional team members to help ensure a fully supported product
upon General Availability. This consists of the following activities which are applicable to
Product Readiness only (see Figure 3).

Page 6 of 10 Version changed on: Thursday, February 06, 2014

SQM - Saba Quality Methodology

Figure 3 – Please note number of planned sprints can change based on length of release cycle

 Product Readiness Kickoff: Meeting to bring the cross-functional leadership team into
the product development process and provide a knowledge transfer session of
upcoming new features and product enhancements.

 Overview Training: Training for internal teams and partners covering the business
value of the release. Answers the question, “Why are we building it”.

o Audience: Available for all of Saba, Partners, and may be posted within Saba
Customer Community

o Delivery: May not occur for every Product Release as this training is dependent
on the scope of the release and business and market needs.

Version changed on: Thursday, February 06, 2014 Page 7 of 10

SQM - Saba Quality Methodology

 Feature Training: Training for internal teams and partners covering the detailed
workings of new functionality from the end user and administrator perspectives.
Answers the question, “What did we build”

o Audience: Engineering, Operations, Support, Solution Consultants,

Implementation Teams, Product Marketing, Product Management, Saba Partners

o Delivery: Available for Product Releases

 Technical Training: Training for internal teams only and covers the technical details of
the new features and any platform or infrastructure changes. Answers the question,
“How did we build it”

o Audience: Engineering, Operations, Support, Solution Consultants

o Delivery: Available for Product Releases

 Internal Product Availability: During the stabilization phase, internal team members
are able to access test environment tenants which have been pre-populated with demo
data for the purposes of familiarizing themselves with the newly developed functionality
and build their readiness materials.

 Customer Training: Saba team members deliver “What’s New” training to customers
as needed.

For other Product artifacts such as Product Documentation & Training sign-offs, please see
SOP-SDL-05-02, Cloud GA Readiness.

2.7 Release Postmortem

After each Project, cross-functional leads meet to discuss the following:

 What went well?

 What needs improvement?

 What can we do differently, in the upcoming release to improve?

If any of above topics need discussion and/or further analysis, it can be taken offline with
relevant members and the outcome published to the entire group of Engineering leads.

Page 8 of 10 Version changed on: Thursday, February 06, 2014

SQM - Saba Quality Methodology

3 SOP Exceptions

From time to time there will be a need for making exceptions to standard operating procedures
due to business drivers. Exceptions to the completion of identified steps in the process
described above require documented approval (including a brief summary of business
justification) from one of the following Saba team members or their identified delegate:

 Sr. VP of Engineering and Operations

 Sr. VP of Products and Technology

Sustained only products may manage certain portions of their SDLC resources, infrastructure
and artifacts based on their legacy procedures.

Version changed on: Thursday, February 06, 2014 Page 9 of 10

SQM - Saba Quality Methodology

4 SOP Change Log

The Change Log is used to keep a record of the changes made to the Standard Operating
Procedure. An entry only needs to be added each time it is published, although the author may
want to include intermediate steps.

Version Date Who Action

1.00 08/01/2011 Klaus Salchner Created initial version of this document
2.00 08/21/2011 Klaus Salchner Misc. Changes
3.00 08/24/2011 Ben Jahansetan Final Draft version review and changes
4.00 01/03/2014 Matt Ready Updated for FY14
4.01 02/03//2014 Ben Jahansetan Reviewed / Edited FY14 Updates for consistency and
completeness

5 SOP Sign-Off

The Document Sign-Off is used to record who has reviewed and approved the Standard
Operating Procedure.

When Who Department

e-signature Ben Jahansetan Security & Compliance
in S@W

Page 10 of 10 Version changed on: Thursday, February 06, 2014