1. Rapid agile release flow
and the agile testing
Shirly Ronen-Harel
Aug 2010
http://il.linkedin.com/pub/shirly-ronen-harel/0/653/249
shirly@agilesparks.com

2. • The following presentation will describe a
short flow of daily uploads to production
environment while the sum of those daily
uploads results with a business and customer
release, While The testing in this case is
manual regression tests, no automation tests
exists yet.
• This is an agile team solution for dealing
with on going releases to production of
PSP’s while at the same time not released to
an end customer.

3. • This may fit companies working with internet
products which PSP’s must be released on
a short period of time basis and autometion
regression tests having a low coverage of
product functionality.
• Some of the rapid release flow may fit to
an internal customer tools development or
any product development.
• We are distinguishing between a daily upload
of PSP (potentially shippable product) and
a final release to customer use.

4. Production change request
Business release
Station- Customer release

5. The company holds three types of release :
1. CR :Production change request of user stories group: Release from development to production
environment:
• This is a process that is managed on a day to day basis where potentially shippable products (PSP’s)
are integrated into the code main trunk and uploaded into the production environment
• It does not mean that they are released or open to users use yet
• These small releases allow continues functional integration into the production environment without
overload users or internal customers with new frequent changes.
• Each production upload is managed as a production change request as a part of the change
management process in the organization
1. A business Release
• Milestone (sometime periodical sets of milestones) where the product organization decides to issue a
business release containing the PSP’s (potentially shippable product) that were uploaded to
production so far.
• From this point on , no new features will enter into the customer release..
• Internal customer acceptance tests can begin .
1. Station - Customer release
• a frequent small release to customer , that has a name and a number , , which was developed for
few iterations(1-3) and has a millstone and ETA for release to customer/users use.
• It is usually part of a bigger version release.
• This release is prepared for some time , including relevant marketing materials and training for users
.

6. R – business release takes the entire CR’s so far uploaded to production and
close them to a release not yet release to customer. Development and
upload of CR continues but will be integrated to the next R.
Customer related tests /pilot may begin at this stage.
CR – (user stories group) Agile development S - Customer release:
team uploads PSP’s to production , sometimes The product is release to customer including
on a daily basis. This process is managed as documentations and all preparations the business
change request process of production change needed to do in order to be able to prepare customer
control. for a quality release.
Uploads of PSP to production demands the architecture ability to
split between production and customer releases.

7. Release/CR/Stations
No customer releases (s) is allowed between stations (s).
There can be many CR’s released during the iteration (with a quality
definition of done)
Sometimes there are delays in delivery of business features to the R
milestone.
Once an agile team miss those R milestones ,with features to be
released , those features will be moved to the next R station.

8. User stories (US) Freeze
US freeze US freeze US freeze
Business release Customer
release
No new user stories can enter (unless major exception is required) a Sprint/Iteration
after the planning session is set and team commits to sprint goals and
artifacts.

9. Code Freeze
US freeze US freeze US freeze
Code freeze is set
before any CR or PSP

10. Backlog user stories Freeze and code Freeze
Top 3 (n) user stories freeze
According to team WIP Team should work on top n` user stories only.
,
Other user stories , that are in the backlog ,are not yet coded . They
are Only elaborated and acceptance criteria are defined.

11. 1 Working on top
user stories
Once a user story is
developed (and done) , the
team is allowed to pick up
the next user story and code
2 it (obviously- including
testing).
The next in line user story ,
ready with acceptance
criteria is entering the list
of top n worked user stories.

12. User Story Code Freeze
Just before a user story is done, team freeze code , and
regression tests starts(Manual tests).

13. User Stories Quality Tests
Each user story is
tested for its tasks,
its functionality and
with other user
stories for a group
regression tests, As
part of a mini
hardening tests
phase.

14. Release End Game Tests
US freeze US freeze
Business release Business release
Freeze
Before business release (R) the team will perform the end game tests ,
packaging and final quality verifications.

15. R&R
•Product manger is Responsible
for the product plan.
•PO : Product owner preparing
release and sprint backlog.
•Scrum team : ‘Development and
testing’ is responsible for quality.
•Code freeze is a mutual decision
between Po and scrum team.
•Upload to Staging environment is
a mutual decision between PO,
Release manager and scrum team.
•Upload to production environment
is a mutual decision between PO,
product manager and Release
manger .
•Business release is a decision for
product release to make.

16. The company mature agile operation performs this
flow in a days<->weeks time farms. and it works!