Scrum Strategy – The Dev Team Improvement Backlog

The strategy I describe below is one I’ve used successfully in coaching Scrum teams. Your mileage may vary, of course.

Overview

• The Dev Team has a thing called the “Improvement Backlog”, where it keeps a list of things(Improvement Backlog Items — IBI’s) that are intended to improve the Dev team’s productivity.

Purpose

• The purpose of the strategy is to create a culture of self organization and “inspect and adapt” improvement within the Dev Team.
• The strategy also acts as a platform for allowing the Scrum Team to resolve technical debt, though technical debt is just one type of potential improvement. As an aside, bugs are not technical debt. Bugs should be handled differently. See more about technical debt under the “Considerations” heading below.
• This strategy is an implementation of the Improvement Community/Improvement Backlog concept that Mike Cohn talks about in Chapter 4 of Succeeding with Agile. More on that below under the “Other Notes.” heading.

Preconditions

• The Dev Team has enough flexibility from management and/or the Product Owner to carve out a small amount of time each sprint for productivity improvement. The rule of thumb I use is 10-20% of each sprint. If you have trouble convincing management, you might try asking management how much they know about the 7th habit of highly effective people.
• The Dev Team is not in the habit of creating new technical debt, testing debt, or process debt. You need to stop the bleeding before you can stay current and catch up. This strategy is about staying current and catching up, so don’t use it until your team has stopped the bleeding. For help with stopping the bleeding, have your Dev Team add “creates no new technical, testing, or process debt” to their Definition of Done(DoD) and work on that strategy first. If you already have a good DoD and your team faithfully adheres to it, you probably don’t need that statement.

Strategy

• The Dev Team has a thing called the “Improvement Backlog”, where it keeps a list of things(Improvement Backlog Items — IBI’s) that are intended to improve the Dev team’s productivity. (Note that I did not say velocity, as I do not believe velocity to be a direct measure of productivity, and I believe that software productivity can’t be directly measured). This backlog has many different things on it, and it is ordered by the Dev Team. The types of things are essentially anything that *might* have the chance to improve team productivity, while at the same time allowing the team to keep a sustainable pace. I say “might” because we want to create a culture where it is safe to experiment.
• Examples of IBI’s:
  • Team celebrations
  • Scrum process improvements
  • Technical Debt resolution
  • Bug Fixing (rare, but if it can improve Team productivity it’s ok)
  • Exploring new technologies
  • Attending Conferences/Training
• Each item is groomed, estimated^1, and ordered, just like PBI’s.Further, it’s best to break these down into smaller items that can be done incrementally, when possible. The Dev Team can use the retrospectives to feed and groom the IB, or any other time (formal or informal) to add to it. Like PBI’s, only the ones towards the top of the backlog are well groomed. The Dev Team can choose to invite the PO into the grooming activity if they so desire, but it is not required. The IB is ordered based on many factors, but the Dev Team is responsible for maximizing the productivity value of the IBI’s to the team and the wider organization.
  • ^1 These items should NEVER be estimated in story points, NOR counted in velocity, and these items should not end up on the Product Backlog. I prefer hours to estimate them, but any other unit (real or fake) can be used to do relative sizing of the items, so long as the unit is not confused with PBI’s, User Stories, or velocity — which are entirely different concepts.
  • These items should never represent code or testing around Product Backlog Items. If you need to improve the code or testing around the functionality of a PBI, then incorporate the “clean up as you go” time(also known as the Boy Scout Rule ) into your estimate for the product backlog item. IBI’s are specifically for things that are not directly related to PBI’s.
• How much time do we dedicate to the IBI’s each Sprint?
  This is entirely up to the Dev Team, but made visible to the PO and the wider organization. Making them visible on a team’s “Scrum board” is sufficient. These items can be planned in the Sprint Planning Meeting, or outside of it, but they should probably end up as part of the Sprint Backlog, just like PBI’s do. I find that the best way to dedicate the time is to negotiate with the PO on some number between ~10-20% of each Sprint. The Dev Team should let the PO influence that number, but not control it. Also, there may be circumstances where the team decides to use a much higher or lower % of the Sprint, but the team had better be darn sure that they can justify the outlier to the PO and wider organization.

Considerations

• In my opinion, this strategy is quite useful for almost all teams that meet the preconditions mentioned above.
• This strategy should never be used as a “dumping ground” for deferring work of any kind. See the precondition above about “no new debt.”
• Some teams execute this strategy by putting these items on the product backlog. I don’t like this for numerous reasons. The most important reason I don’t like it is because it incorrectly gives the PO authority over something that is clearly the domain of the self organizing Dev Team. The PO owns the “what features” part of Scrum, and the Dev Team owns the “how we deliver features” part of Scrum.
• I have found that this strategy is a huge morale booster to Development Teams and really increases the self organization aspect of the Dev Team.
• It is very difficult to measure productivity increases in software development, but anecdotally I have observed significant productivity improvements when this strategy is implemented.
• Resolving technical debt is a tricky thing. Most people define technical debt incorrectly, in my opinion. I essentially subscribe to Martin Fowler’s view of Technical Debt as a definition. It’s hard to predict the value of resolving technical debt, and many believe that you should never resolve technical debt unless it is directly related to a product backlog item being implemented. As such, I encourage teams to prioritize technical debt inline with any other items on the Improvement Backlog that could improve their productivity. This tends to lead towards fewer technical debt items being worked on, so it lowers the risk of doing non-valuable work. At the same time, it leaves open the possibility that the Dev Team really does believe that resolving technical debt is an improvement worth pursuing.

Other Notes

• I recommend that Dev Teams utilize this strategy *in addition to* the incremental cleanup strategies like the Boy Scout Rule.
• I’ve based this strategy on a couple of similar strategies:
  • http://blog.mountaingoatsoftware.com/how-do-you-get-from-here-to-agile-iterate
    • More here: http://www.mountaingoatsoftware.com/system/asset/file/149/04-Iterating-Toward-Agility.pdf
      • In Cohn’s example, the Improvement Community(IC)/Improvement Backlog(IB) is centered around the goal of adopting Scrum, but he also makes the point that an IC can be focused on any group of individuals with any goal of improvement. In this case, our group is the Dev Team and our goal is Dev Team productivity improvement.
  • https://sites.google.com/a/scrumplop.org/published-patterns/retrospective-pattern-language/scrumming-the-scrum
• I justify this strategy by using some language in the Scrum Guide, most notably:
  • “No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;”