One of the things that I always hear about agile development and scrum in particular is the idea of creating a releasable piece of software at the end of every sprint. This is usually redefined into “a potentially releasable piece of software” at the end of each sprint. It tends to be a little more grey than that, some sprints produce a deliverable that is more potentially releasable than others so there are an infinite number of levels of potential between actually releasable and only hypothetically releasable.  Almost all of the scrum teams that I have worked with over the last 15 years have all been on the “potentially releasable” and of that spectrum.

There’s a huge difference between “potentially releasable” and “releasable”; it’s the difference between having gotten a speeding ticket and actually being a race car driver. As an experiment, the team that I am currently the scrum master for has been releasing at the end of every sprint; this has made some interesting changes in the way that we approach everything. From the last several sprints, actually releasing software at the end has made the entire process more disciplined and focused. The changes started at the tail end of the feature life cycle and continue to work their way forward through the whole process.

QA and User Acceptance

The first to feel the pain was testing features. Obviously, if you’re releasing on the fixed date, the testing must be done by that date. That meant that testing required enough time to test, so the time constraint for testing became an issue. Part of the changes was that testing moved to smaller batches; for sanity’s sake, you couldn’t just wait until the last feature was developed to start testing. Testing and user acceptance needed to be a much more continuous process. The other part of that is that it brought up some more realistic demands from the testers about “is the feature ready yet” and suddenly, there became deadlines for when work needed to be done so that it could be tested before the end of the sprint.

This produced several changes:

  1. More QA involvement earlier in the process
  2. Needing time to test became important
  3. More opportunities to do things in parallel with development were found.

Development

There were really four changes that went on in development to switch to really releasing at the end of each sprint. Finishing development earlier was a big part of it. Knowing what the story really meant was another big part of it. The other changes were in how the relative priorities were evaluated.

In the “potentially releasable” world, a developer saying that the feature is finally “ready to test” an hour before the sprint planning is OK; because it’s “potentially releasable”. The development is done, if no bugs were found then that build an hour before the sprint officially ended was “releasable”. Getting it done at the last minute like that seems like an agile tradition, but it had to go. Changing this mindset was tough, partly because there’s also the assumption that “early in the sprint QA is still finishing the stuff from last sprint.”

So one of the changes has been to pick more “low hanging fruit” to make sure that there are things that are ready to test as soon as possible. Getting things to QA quickly becomes a priority and affects the priorities of the stories in the sprint.

The other main change was in how risk was evaluated. Now part of the evaluation of the work includes the time it takes to test it.  So it’s more important to have the things that take longer to test developed sooner than the things that take only a few minutes to test. The end result of this is that the QA effort tends to be more balanced.  There is less idle time at the beginning of the sprint and not as much time pressure at the end of the sprint.

lenges The last major change was in the level of detail for stories to be acceptable for the sprint. In the “potentially releasable” world, you can take an undefined or vague story and use time in the sprint to do the discovery of what was really meant. When there is the very real constraint of needing development done in time to test and some development and testing tasks going on simultaneously, there is a lot less room for ambiguity. More to the point, ambiguous stories could no long be accepted into the sprint.

The changes that this produced:

  1. No waiting until the last minute to complete development
  2. Get some things ready to test as quickly as possible
  3. Testing effort/risk affects priority
  4. Ambiguous stories aren’t ready to develop

Product Management and Story Creation

The main change for story creation was that there is a lot less room for ambiguity. This is our current challenge and we’re still working on it. So far, it’s mainly focused on removing ambiguity from the stories. When everyone understands the same thing after reading the story, then work can be done more quickly.

The areas for improvement so far:

  1. Well defined products from the story
  2. Smaller, more granular stories
  3. Tighter, more specific language

When all is said and done

In then end, changing to actually releasing at the end of the sprint has been a positive change.  There have been rough spots and there will continue to be challenges.  The discipline needed to really live up to the expectation has been a wild ride at times. So far the change has been a positive experience, throughput of features has been faster, quality has been more consistent and communication has improved.

 

Advertisement