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

Re: [scrumdevelopment] Re: Pointing debt stories

Expand Messages
  • RonJeffries
    Hi Sean, I ll give your note a deeper look as time permits. Just one thought-provoker for now: ... First, remember that unlike not paying our Visa bill, the
    Message 1 of 117 , Apr 2, 2012
      Hi Sean,

      I'll give your note a deeper look as time permits. Just one thought-provoker for now:

      On Apr 2, 2012, at 7:35 PM, Sean Corfield wrote:

      I look at the math here and it feels sub-optimal to me to end up paying more interest due to deferred treatment of known technical debt - it "costs" more - whereas a one-off payment up front may hold up one sprint but overall "costs" less. And I feel that to get a one-off payment agree, requires buy-in from the PO (since it trades off time in a sprint that would otherwise be spent on stories).

      First, remember that unlike not paying our Visa bill, the interest does not increase when we're not working in that area of the code. This is why it [almost?] never makes sense to refactor because "someday we're gonna need it". 

      Certainly, if we are going to do a one-off, we need buy-in from the PO. I emphasize the IF. 

      In such a case, I would favor the team explaining to the PO that they need the time, and why, rather than asking the PO to prioritize technical stories. To me, with the former approach the team is proactively dealing with the problem and negotiating for the time to do it, while when the PO prioritizes, it's more like the team just waits for the PO to decide to do some technical story.

      However, I am [almost?] never inclined to exercise the one-off, because in my experience, no one benefits.

      There are serious issues with this form of speculative refactoring. Some of these are:

      • We really do not know what the business-side code wants to be like. We have some guess at that, of course. But why guess? Why not let real code, reflecting actual needs, participate in the design improvement?

      • We will be deferring some number of stories while all this goes on. This delays production of value that we have to recover before the refactoring really pays off.

      • We are very likely to over-design when doing speculative refactoring. We will be feeling the pain of our inadequate design, and we'll want to put in everything to be sure that we never have an inadequate design again. Too much design is almost as bad as too little.

      • Quite often -- almost invariably in my experience -- "large refactoring" really means "rewrite". It is very misleading to refer to a rewrite as a refactoring. It minimizes the real risk of what we're doing. Contrariwise, a small refactoring is not a rewrite, and comes with disproportionately smaller risk.

      • Much of this effort -- usually most of it -- will not pay off for a long time. The existing stories do work. If they did not, or there were performance problems, we wouldn't be talking about a technical story, we would be talking about a business story. The next new story isn't like to exercise everything we do in a "large refactoring".

      Refactoring in small steps, in response to actual stories, mitigates all these concerns:
      • Our refactoring is based on actual need, not speculation.
      • Story production continues, perhaps at a reduced pace but perhaps not.
      • We design only what we need.
      • We must only refactor, we cannot rewrite. 
      • Every bit of work we do pays off right away.

      I've done it both ways. I was probably on the very first Agile project ever to negotiate a technical recovery story. It paid off, in the sense that we got away with it, and we did get some benefit. In retrospect, we'd have done better to do things incrementally. We just didn't know how important it was, and, probably, we weren't as yet skilled enough.

      I would never submit technical questions to the Product Owner for determination.

      I would almost never negotiate for a large refactoring as you describe here, though if I needed to do one, I would negotiate as you suggest. It's just that I can't think of a time when it's really desirable to do a big bite, so I hesitate to leave it out as if it's a viable option. Generally speaking it is survivable but hardly ever optimal, if it ever is.

      Regards,
      Wisdom begins when we understand the difference between "that makes no sense" and "I don't understand". -- Mary Doria Russell

    • Charles Bradley - Scrum Coach CSM PSM I
      I have now more completely documented my version of the improvement backlog concept here:
      Message 117 of 117 , Apr 19, 2012
        I have now more completely documented my version of the improvement backlog concept here:

        http://scrumcrazy.wordpress.com/2012/04/19/scrum-strategy-the-dev-team-improvement-backlog/
         
        -------
        Charles Bradley
        http://www.ScrumCrazy.com




        From: Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...>
        To: "scrumdevelopment@yahoogroups.com" <scrumdevelopment@yahoogroups.com>
        Sent: Tuesday, April 3, 2012 12:13 AM
        Subject: Re: [scrumdevelopment] Re: Pointing debt stories



        Peter,

        Velocity and Story Points are concepts intended to capture new behavior of a system that is directly valuable to primarily users and purchasers.  (The What) 

        Improvement Items are only indirectly valuable, and thus, should be tracked totally separately and differently.  (The How)

        This is also why I give the Dev Team the final control on Improvement Items, and leave the final control on User Stories to the PO. 
         
        As for who sponsors improvements that cost money (whether it be celebrations, new tools, etc) -- it's the same people who have sponsored them before -- either the org, or the individual members pay for it themselves.  Obviously the Dev Team would need to get permission from the org to spend org resources(just as before, only now we're making it more visible via the Improvement Backlog).

        -------
        Charles Bradley
        http://www.ScrumCrazy.com




        From: trudelle <trudelle@...>
        To: scrumdevelopment@yahoogroups.com
        Sent: Monday, April 2, 2012 11:48 PM
        Subject: [scrumdevelopment] Re: Pointing debt stories

        Thanks Charles, this sounds quite reasonable to me, and seems like it could handle 80-90% of the of the situations I've encountered. I'm not sure I understand why you're so against using points here though, or why you think the cost is so different from velocity (which I agree is not a measure of productivity).  Also, who sponsors expenses like conferences & celebrations?  It seems like these involve tradeoffs with competing ways of spending the team's time/money, which could be contentious.

        Peter

        --- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:
        >
        > Peter,
        >
        > 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:
        >
        >     * http://blog.mountaingoatsoftware.com/how-do-you-get-from-here-to-agile-iterate
        >     * https://sites.google.com/a/scrumplop.org/published-patterns/retrospective-pattern-language/scrumming-the-scrumI 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
        > http://www.ScrumCrazy.com
        >
        >
        >
        >
        >
        > >________________________________
        > > From: RonJeffries <ronjeffries@...>
        > >To: scrumdevelopment@yahoogroups.com
        > >Sent: Sunday, April 1, 2012 3:47 PM
        > >Subject: Re: [scrumdevelopment] Re: Pointing debt stories
        > >
        > >
        > >
        > >
        > >
        > >
        > >
        > >On Apr 1, 2012, at 4:54 PM, trudelle wrote:
        > >
        > >--- In scrumdevelopment@yahoogroups.com, RonJeffries <ronjeffries@> wrote:
        > >>
        > >>because you're focusing on the PO's idea of value, you'll never work > on a debt item that doesn't really need it.
        > >>>
        > >>Ah, but you're not.  You're focusing on the PO's rank ordered stories, which are invariably value/cost.  If the PO doesn't understand persistent reasons for high costs on some stories, you may never work on the debt that keeps the highest value items low in the backlog.  In some cases, several stories could presume some significant refactoring, whereas the reality is that some single tech story could be identified that is the common work needed before implementing all of them.  If POs could see this, they would order the backlog very differently. How are you handling that without tech stories?
        > >
        > >Well, the main thing I would do is have stories all about the same size. Also, research results by Arlo Belshee, in a related but not identical context, suggest that ordering by value alone may work better. I believe that there, too, stories were not allowed to go infinitely large, else we'd all be working on teleporting and such.
        > >
        > >
        > >If I understand your concern, it is that some stories will take a long time to do unless ... unless what? Unless some refactoring is done first? I deny that premise. It doesn't take me measurably longer to do stories that need refactoring.
        > >
        > >
        > >If it did, then I'd take the aforementioned list of refactorings, and tag the business-value stories with an indicator of which ones impacted which refactoring areas. I'd encourage the PO to think in terms of value, not time. 
        > >
        > >
        > >It seems to me that to give the PO useful information, you'd have to be able to say, even with your big refactoring style, "If we do refactoring R3, then stories S4, 5 and 6 will change estimates from 10, 12, 20 to 5, 5, and 8.
        > >
        > >
        > >And if you can do that, you're a better man than I am, and I'd love to read a paper on how to do it. Since I don't know how to do that, I'd rather just keep all the stories about the same size and clean the code as I go. I can actually do that, and I cannot predict the velocity impact of a large refactoring. 
        > >
        > >Ron Jeffries
        > >www.XProgramming.com
        > >I know we always like to say it'll be easier to do it now than it
        > >will be to do it later. Not likely. I plan to be smarter later than
        > >I am now, so I think it'll be just as easy later, maybe even easier.
        > >Why pay now when we can pay later?
        > >
        > >
        > >
        > >
        > >
        > >
        >




        ------------------------------------

        To Post a message, send it to:  scrumdevelopment@...
        To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

        <*> To visit your group on the web, go to:
            http://groups.yahoo.com/group/scrumdevelopment/

        <*> Your email settings:
            Individual Email | Traditional

        <*> To change settings online go to:
            http://groups.yahoo.com/group/scrumdevelopment/join
            (Yahoo! ID required)

        <*> To change settings via email:
            scrumdevelopment-digest@yahoogroups.com
            scrumdevelopment-fullfeatured@yahoogroups.com

        <*> To unsubscribe from this group, send an email to:
            scrumdevelopment-unsubscribe@yahoogroups.com

        <*> Your use of Yahoo! Groups is subject to:
            http://docs.yahoo.com/info/terms/







      Your message has been successfully submitted and would be delivered to recipients shortly.