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

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:

 p1.png

p2.png

 

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:

 

Item

Criteria

Test Coverage

100%

Quality

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

Performance

No open issues

Security

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:

 

 p1.png

p2.png

 

 

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):

 

Step

Input

Output

Owner

Participants

When

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

GL

FA, RM

1st day of sprint

Implementation

Automation

Defects fixes

User stories/Tasks

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

Developers

FL, QA

Days 1-8 of Sprint

Testing

Checked in, reviewed and automatically tested code

Verified user stories and defects

QA TL

QA

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

Developers

Developers

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

 

FA

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

RM

Everyone is involved

End of sprint/push to production sprint

Daily Standup (Scrums)

 

Tasks tracking

Remove Impediments

Dev TL

Feature team

Daily

 

 

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.

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Malcolm is a functional architect, focusing on best practices and methodologies across the software development lifecycle.
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.