Agile Techniques for Managing Work Items
Upcoming SlideShare
Loading in...5
×
 

Agile Techniques for Managing Work Items

on

  • 4,408 views

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 ...

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.

Statistics

Views

Total Views
4,408
Views on SlideShare
2,576
Embed Views
1,832

Actions

Likes
0
Downloads
57
Comments
0

5 Embeds 1,832

http://toolsforagile.com 1823
http://webcache.googleusercontent.com 3
http://translate.googleusercontent.com 3
http://www.linkedin.com 2
https://www.google.dk 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Agile Techniques for Managing Work Items Agile Techniques for Managing Work Items Presentation Transcript

  • Agile Techniques for Managing Work Items
  • 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.
  • 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.
  • 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.
  • * * 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.
  • * * 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.
  • * * 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.
  • 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
  • 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.
  • Siddharta Govindaraj siddharta@silverstripesoftware.com http://ToolsForAgile.com Twitter: @silvercatalyst Facebook: http://www.facebook.com/ToolsForAgile