As I write this entry, we're in the middle of Sprint Planning for our coming 30-day development sprint. The development team is behind closed doors.
More than any time in recent memory, this planning session required tough trade-offs. Part of the trade-offs were prompted by recent changes in our processes. I'll explain.
In previous development sprints, we generally offered a release at the end of the sprint. On the positive side, customers could choose to have early access to new features and bug fixes. On the negative side, frequent updates represent change and our capacity to absorb change is not unlimited.
In response to these conditions and customer feedback, our management and development teams collaborated to tweak the process slightly as follows:
There will still (generally) be a release available at the end of each sprint, but in most cases it will be a patch release. Meaning that it will only include bug fixes. The good news is that a defect can still be fixed by the end of the following sprint.
New feature releases (generally considered higher risk) will be announced with less frequency... perhaps once each quarter or less. Here's the trade-off... we have approximately 32 Product Backlog Items that represent functionality that customers identified specifically. In previous sprints, that work had the potential to be released at the end of the sprint. Under the tuned process, that work will be released as part of a subsequent sprint.
We believe, however, that this strategy will improve quality because patch releases have a smaller chance of introducing new defects (because the changes are targeted and specific).
Comments