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

49506Re: Keeping cross-cutting tasks visible (without technical stories)

Expand Messages
  • tobias.mayer
    Dec 6, 2010
      I can't take credit for it either. I first witnessed this with a team I worked with at Business Week in NYC. It emerged from the collective consciousness of the team. As I recall this is what they did (just expanding on Carlton's description):

      Whenever they found technical debt, or any kind of code problem that needed fixing, they didn't fix it unless it was essential to complete the story they were working on (this took some discipline). Otherwise they wrote a sticky note (a task) and added it to a special box on the visual management wall labeled Technical Debt. This served two purposes: a reminder to the team, and a visual representation to the business of the state of the codebase.

      At any subsequent planning meeting, when the USER-FACING stories were discussed (I don't buy into the concept of "technical stories") someone may remind the team that if such-and-such a story was attempted then certain code debt items called out on the wall would need to be fixed as part of that story. The rule was "no workarounds". This clean up work was then considered as part of the essential work of the story, and the story was estimated accordingly.

      These tasks were NOT part of the backlog, they didn't get prioritized and were never fixed in isolation. Instead, when the story was estimated and committed to, these tasks simply became extra tasks towards the completion of the story. It was very elegant, very simple and it worked well for that team. Code debt got cleaned up when doing so resulted in value to the user.

      And visually everyone could see the results of that clean up: An fast-emptying space on the wall.


      --- In scrumdevelopment@yahoogroups.com, "banshee858" <cnett858@...> wrote:
      > >
      > > > List all the technical debt stuff on little post-it notes
      > > > adjacent to the Task Board. When a Product Backlog item (PBI) is
      > > > selected for a Sprint, look at the technical debt pieces and find
      > > > the pieces that make sense to finish while working on the PBI.
      > > > Add those to the scope of work for the PBI and estimate how long
      > > > it will take to complete the feature and the technical debt pieces.
      > >
      > > > That way you make the technical debt work visible, you can
      > > > prioritize it and link it to real value.
      > >
      > > Very nice!
      > >
      > Not my idea - it came from Tobias Mayer.
      > Carlton
    • Show all 28 messages in this topic