Agile teams need to handle new feature development for upcoming sprints in parallel with maintenance stories from previous releases. Add to the mix technical stories (refactoring, build, development environment) from the team itself.
How can we effectively handle these non-feature stories effectively?
In this presentation we look at a few techniques to do this.
2. Agile teams need to handle new feature development for upcoming sprints in
parallel with maintenance stories from previous releases. Add to the mix
technical stories (refactoring, build, development environment) from the team
itself.
How can we effectively handle these non-feature stories effectively?
In this presentation we look at a few techniques to do this.
Lets assume that we have four work items and that every work item takes one
day to complete.
Quick terminology note: Bug refers to a bugs found after a sprint release. Pre-release bugs are
usually fixed before release.
3. This technique involves having a single backlog containing
both new feature stories as well as bugs and support stories.
The whole list is prioritized and the team works from the top
of the list.To do this effectively the product owner needs to
understand all the perpectives involved in prioritizing the list.
This method obviously guarantess that the team is always
working on the most important story.
4. In this method you have multiple lists for each type of story.
Each list is prioritized by the person who maintains the list.
Together they form the product owner team.
The PO team gets together and discusses top items from each
list and combines them into the upcoming backlog. This is
useful when the product owner doesn't have complete
understanding on all the different perspectives.
This method also guarantess that the team is always working
on the most important story.
5. *
* This support item is 5th priority but it is scheduled at the end of
sprint 2
You maintain independent lists and divide up the capacity to
handle each one. For example, the team may decide to spend
one day a week on bugfixes, one day on technical stories and
three days on new features.
This method is fairly simple, but also suffers from the problem
that you may end up doing low priority new feature at the
expense on a high priority bug fix and vice versa.
6. *
* This bug is 3rd priority but it is scheduled in sprint 3
An alternate approach to the previous technique is to allocate
capacity by sprint. For example, two sprints of new feature
development followed by one "hardening iteration" of only
bug fixes.
This is a method suffers from the same problem. Furthermore,
pushing even critical bug fixes to a dedicated sprint dilutes the
ability to keep the software always releasable. This also
encourages mini waterfalls between releases.
7. *
* This feature is top priority but it is scheduled in 6 th
This strategy is popular with zero-defect teams.
The problem with this is that you may end up fixing a number
of low priority bugs when you could instead be working on an
important new feature.
8. The worst solution of the five*, but perhaps the easiest for an
organization that is not used to combining new development
and maintenance. Simply maintain separate teams to handle
each type of story.
* See http://toolsforagile.com/blog/archives/383
9. Comparison between methods
The first two options, single prioritized backlog and multiple prioritized lists guarantee that
stories are worked in the right order of importance.
Single prioritized backlog works best when the product owner has all the perspectives to
understand the importance of a refactoring vs criticality of bug vs RoI on a new feature. The
product owner often doesn't have all the perspectives. In this case multiple prioritized lists, each
maintained by someone who understands that perspective, is a better choice.
Allocation by capacity division is useful if there is a large number of low priority bugs that you
want to clear up over time, but do not want to stop new feature development in the interim.
Allocation by sprint is a popular way to deal with bugs, but is generally a bad idea.
Always fixing bugs is also a bad idea because it doesn't take into account the relative importance
between bugs and new features.
Using separate teams is a holdover from traditional processes. There are many problems with
this setup. Read http://toolsforagile.com/blog/archives/383 for some views on this.
