Loading ...
Sorry, an error occurred while loading the content.

54687Re: [scrumdevelopment] Re: Pointing debt stories

Expand Messages
  • Sean Corfield
    Apr 1, 2012
    • 0 Attachment
      Thank you for this Charles. It makes me feel a lot better about how we're trying to manage things at World Singles, in terms of identifying improvements and consciously deciding when to defer them and when to roll them into a sprint.

      I think part of my issue with the way Ron and George characterize technical debt is that they (seem to) take a dogmatic view that if you aren't doing continuous incremental improvement, the only other option is overwhelming technical debt and that it is against that background that future decisions of refactoring vs user story becomes the "bad either/or dichotomy" that is being held up here as so wrong.

      From an idealistic p.o.v. as well as a pedagogical one, promoting continuous incremental improvement makes perfect sense because it is, by definition, the ideal way to operate - something we can all aspire to. On the other hand, I'm glad that there are also pragmatic voices here who are willing to discuss ways to handle trade offs and and alternatives to a "pure" approach, to look at how those can work - or not - rather than simply dismissing such variations as "sub-optimal" :)

      To be clear, I'm interested in both sides of the coin. I like hearing about the ideal approach as a goal and ways to constantly improve toward that. But I also like hearing about how others deal with things that crop up in most people's real world jobs (and I'm pleased that some people find they don't have to deal with these things :)

      On Sun, Apr 1, 2012 at 4:36 PM, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:


      My solution is essentially this:
      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 (but not necessarily velocity, because I do not believe velocity to be a direct measure of productivity).  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 allow the team to keep a sustainable pace. 

      Examples of IBI's:
      • Team celebrations
      • Scrum process improvements
      • Technical Debt resolution
      • Bug Fixing
      • Exploring new technologies
      • Attending Conferences/Training
      Each item is ordered and estimated*, 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 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.

      * These items should NEVER be estimated in story points, NOR counted in velocity, and these items should not end up on the PBI.  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.

      How much time to dedicate to the IBI's each Sprint?
      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.  Also, make sure that having an IB is not going to get you or your team fired or anything like that!

      Further, I recommend that Dev Teams utilize this concept, *in addition to* the incremental cleanup strategies as recommended by Ron and George.

      I've based this concept on a couple of similar (but not the same) strategies:
      I justify this 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;"

      I probably forgot a few things, so "I reserve the right to revise and extend my remarks at a later time."  At some point I would be open to changing the name of the IB to some other name, so long as the new name is just as good or better. 

      Charles Bradley

    • Show all 117 messages in this topic