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

50228Re: [scrumdevelopment] Refactoring type work in Scrum

Expand Messages
  • Charles Bradley - Scrum Coach CSM PSM I
    Feb 2, 2011
    • 0 Attachment
      >
      > > In the context of Scrum, and based on your previous answer, does the team then
      > > just estimate the size of these backlog items taking into account some extra
      > > ramp up time for each?
      >
      > In the kindest possible way: is there any other approach that could
      > work? If we didn't include this time, wouldn't we fall behind
      > immediately and also ship a new crappy system instead of the old
      > crappy system?

      Approach 1:  Spike Story
      I think, in some of these situations, you could argue that doing a spike story to get ramped up on the newer framework will help remove risk from estimating backlog items that use the new framework.  OTOH, removing large risk and "ramp up time" are not exactly the same thing, so maybe this is not a valid approach.  In this situation, you'd estimate the Spike Story separately.

      Approach 2:  Dev Item
      This is where I walk into territory that I'm not terribly comfortable in just yet.

      Here is one other approach(based on some statements in the Scrum Guide) I've dabbled with in the past when coaching teams.  Maybe I was going off the reservation, or maybe I stumbled onto something interesting.  Not that this approach is not specifically stated in the Scrum Guide, though I think it is a customization within the Scrum Framework that is also consistent with Scrum principles (again as defined in the guide).

      In the past, I've dabbled with the concept of what I'll call "Dev Items", but there is probably a better term for it.  These "Dev Items" are essentially one or more tasks that the dev team creates in a Sprint Backlog.  These items are often not specifically related to what a specific backlog item describes.  They are more related to how the team decides to create a potentially shippable product increment from the current Product Backlog items.  "...Teams are also self-organizing. No one – not even the ScrumMaster -tells the Team how to turn Product Backlog into increments of shippable functionality..."[Scrum Guide quote]  Further, the dev team defines and makes visible, the "definition of done."

      As such , as it relates to the "new framework" scenario I've described, if the dev team feels like they need to use a new framework going forward, they can do so whenever they want to, whether or not the PO is ok with it.

      Interesting notes about Approach #2:
      1.  I coach dev teams that these dev items MUST be made visible in the Sprint Backlog, and MUST be communicated to the PO.  The amount of time a team spends on Dev Items should be a collaboration/negotiation between the team and PO, but in the end, the dev team makes the final decision.
      2.  I coach teams that, because these items are not User Stories, they do not count towards velocity.  As such, their velocity might suffer, and that will be made visible and should be discussed openly as well.  This includes accounting for velocity assumptions used for Release Planning, Sprint Planning, etc.
      3.  Because all of these decision are made visible, dev teams should be careful to only use this time for things that can be well justified to decision makers and whoever ultimately "funds" the team.  If the PO has a direct impact on "funding" the team, then you'd better keep her happy.

      I don't have this entire thing worked out, and I don't intend to be violating some important tenant of Scrum, either.  If anyone feels as if I am, I'd certainly be interested in your thoughts on the subject.

       
      -------
      Charles Bradley, CSM, PSM I
      Experienced Scrum Coach
      My blog: http://scrumcrazy.wordpress.com/



      From: Ron Jeffries <ronjeffries@...>
      To: scrumdevelopment@yahoogroups.com
      Sent: Wed, February 2, 2011 5:14:19 PM
      Subject: Re: [scrumdevelopment] Refactoring type work in Scrum

       

      Hello, Charles. On Wednesday, February 2, 2011, at 6:57:42 PM,
      you wrote:

      > In the context of Scrum, and based on your previous answer, does the team then
      > just estimate the size of these backlog items taking into account some extra
      > ramp up time for each?

      In the kindest possible way: is there any other approach that could
      work? If we didn't include this time, wouldn't we fall behind
      immediately and also ship a new crappy system instead of the old
      crappy system?

      > The main theme of many of these scenarios is technical work on the system under
      > development that cannot be successfully sold to the PO as adding enough business
      > value to bring the technical work to the top of the backlog. Have you ever seen
      > examples of this technical work that cannot be attached to new backlog items,
      > but still should probably be completed for the health of the system under
      > development, or possibly to help increase overall velocity/quality in the
      > future, or possibly some other wise reason?

      Only if you are doing something like changing languages. And even
      then, consider Strangler.

      > (I'm not talking re-writes of major portions of a system here.)(Also, in case
      > you're wondering, I'm not about to advocate the use of the term "Technical
      > Story" or anything like that)

      Feel free to use them if you want to. And feel free to notice that
      your Product Owner cannot understand why they're important, and
      refuses to schedule them.

      Think in terms of why most of us do not eat right or exercise as we
      should. Taking October off to get in shape just won't cut it.

      Ron Jeffries
      www.XProgramming.com
      Wisdom begins when we discover the difference between
      "That makes no sense" and "I don't understand". --Mary Doria Russell

    • Show all 25 messages in this topic