Software Developers
Showing results for 
Search instead for 
Do you mean 

Agile Development at HP - Part 3: Release and Sprint lifecycles

Anonymous_User1 ‎11-26-2013 10:00 AM - edited ‎08-05-2014 05:34 AM

This is the third in a series of five posts that describe the methodology and development processes used by the HP Agile Manager team.  In the first post, I described how we came up with our development processes. In the previous post, I discussed the culture and values of the team, and how we maintain a consistently high level of quality.  Today's post describes the release and sprint lifecycles, and in the next post I’ll describe the feature and user story lifecycles.  The final post will summarize the roles and responsibilities of each member on the team.


Release Schedule

Each release of Agile Manager is developed over four weeks, spanning two two-week sprints. After the second sprint, we branch the source code.  Development continues on the main trunk, while the branched source code is built and pushed to an internal server after a short sanity test.  This internal release is used within HP by other HP product development groups. After two weeks of internal use, the release, including any fixes to defects that were detected in the internal release, is made public to HP Agile Manager customers.


We only make changes to the database structure in the internal build, and upgrade data as necessary.  The upgrade is validated extensively, and only then is it made public. No data structure changes are permitted for a release after the internal release is delivered.


The advantage of this procedure is that releases are pushed monthly with early exposure to thousands of internal customers.  Feedback, including bug fixes, from the early exposure is implemented before the release is made public.


This also allows us to push releases every two weeks. This schedule prevents user confusion over too many changes in a short period of time.


Release Lifecycle

Our release lifecycle is as follows:



We start the planning and scoping of each release around a month (i.e. two sprints) before its scheduled start.  Each release is pushed to internal customers on the second Sunday after the end of the release’s last development sprint.  We roll it out publicly two weeks after that, and formally close the release by conducting a retrospective meeting.


Release Planning and Scoping

The Group Leader, who is in charge of the end-to-end development execution, takes overall responsibility for this stage, during which:


  • The Functional Architect determines the Minimally Marketable Features for the release, and is responsible for taking features from the Product Backlog and adding them to the Release Backlog.
  • The Group Leader works with the development team leaders to determine the development effort and capacity of the development team.
  • The System Architect works with the development team leaders to determine the technical and architectural requirements of the release.
  • The QA Team Leader works with the Functional Architect to define the defects that will be addressed in the release, and to assess the test automation backlog.

The output of this phase is:

  • The Release Backlog in HP Agile Manager
  • List of Feature Leads (typically team leaders) identified by the Group Leader

Release Kickoff

After the work on the release planning and scoping has been completed, the Release Manager schedules a meeting for the first day of the release, where the details of the release are presented to everyone involved – group leaders, architects, developers, testers, etc.


Release Criteria

In the second post of this series, we discussed the ‘Definition of Done’, which is used to ensure that backlog items are completed.  An additional set of criteria is the Release Criteria, which determines whether a release can be made public.  We use the following set of criteria for HP Agile Manager:




Test Coverage



  • No open feature defects
  • No open customer-reported defects
  • No functional regression defects
  • Less than 10 high defects
  • Minimum of 70% medium defects fixed


No open issues


No open issues


I’m proud to note that we consistently achieve these criteria in our releases!



Sprint Lifecycle

Each release consists of a number of two-week sprints, each of which looks like this:





A few days before a sprint begins, we conduct a pre-planning session. On the first day of the sprint, the sprint is planned in detail, and a retrospective is performed on the last day of the sprint.


Days 1-8 are spent working on tasks, and ensuring they conform to the Definition of Done that we explained in the previous post of this series.  Day 9 is dedicated to performing regression cycles on copies of real production projects, and day 10 is reserved for tidying up any loose ends and completing test automation.


Sprint Lifecycle in Detail

Here are the steps in the sprint lifecycle with an explanation of who is responsible for each step (the roles are described in the first post of the series):








Pre Planning

Finalized user stories

Sprint Guidelines

Group Leader (GL)

Release Manager (RM), Functional Architect (FA), QA Team Lead (QA TL), GL

1 day before the sprint starts

Sprint planning and scoping


User stories per team and acceptance tests in Agile Manager

Development Team Lead (Dev TL)

Developers, QA, FA, System Architect (SA)

1st day of sprint

Sprint Alignment


Sprint goals and stretch goals in the MMF



1st day of sprint



Defects fixes

User stories/Tasks

Code is checked in, reviewed and tested (functional, performance and security automation)



Days 1-8 of Sprint


Checked in, reviewed and automatically tested code

Verified user stories and defects



Days 1-8 of Sprint

Regression Tests

Upgraded projects with latest build

regression work plan

100% regression coverage, and any regression defects that were found

Upgrade FL

Developers, QA

Day 8 (preparation)

Day 9 (regression tests)

Defect fixes, and automation


Branch  creation



Day 10 or 11, depending on the number of defects to fix

Sprint Demo

Completed user stories

Demo the user stories that achieved the Definition of Done



For a regular sprint: Dev TL, QA TL;

For a sprint that is pushed to production: Everyone is involved

End of sprint

Sprint Retrospectives



3 things to improve;

3 things to preserve;

Assign owners to action items

Dev TL

Developers, QA

End of sprint

Joint retrospective

Teams retrospective

3 things to improve

3 things to preserve

Assign owners to action items


Everyone is involved

End of sprint/push to production sprint

Daily Standup (Scrums)


Tasks tracking

Remove Impediments

Dev TL

Feature team




In the next part of this series, we’ll examine how the HP Agile Manager team manages the lifecycle of features and user stories.



UPDATE:  Here are the links to the other posts in this series:

Feel free to share your release and sprint lifecycles by leaving us a comment in the box below.


This series of articles was written based on processes and methods developed by Lihi Elazar (Agile Manager PMO) and materials provided by her.  Thanks to both Lihi and to Asi Sayag (R&D Group Leader), for their help, guidance, and extensive reviews of this series.

About the Author


Nov 29 - Dec 1
Discover 2016 London
Learn how to thrive in a world of digital transformation at our biggest event of the year, Discover 2016 London, November 29 - December 1.
Read more
Each Month in 2016
Software Expert Days - 2016
Join us online to talk directly with our Software experts during online Expert Days. Find information here about past, current, and upcoming Expert Da...
Read more
View all