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

Re: [scrumdevelopment] "Business Value" v. "Potentially Implementable Feature"

Expand Messages
  • Cass Dalton
    That s a very interesting insight and is probably the part I ve been getting confused about. I believed that Scrum was supposed to be providing new customer
    Message 1 of 30 , Jul 28, 2012
    • 0 Attachment
      That's a very interesting insight and is probably the part I've been getting confused about.  I believed that Scrum was supposed to be providing new customer value every sprint.  I think I have been overcompensating against the traditional model that doesn't try to provide customer value until the very end. And every time I'm looking to split features and don't end up with new customer value, I feel like my old waterfall mentality has slipped back in.

      On Wed, Jul 25, 2012 at 9:58 AM, David A Barrett <dave.barrett@...> wrote:
       

      There's been a lot of discussion here lately about delivering "business value" each Sprint, and I'm wondering if somehow we've lost track of the underlying concepts of Scrum (at least in this respect), and are simply getting caught in the trap of nit-picking about rules and definitions.  Loosing sight of forest for the trees, if you like.

      I don't recall that ten years ago, when I took the CSM course (taught back then by Ken himself), any mention of "business value" as a Sprint deliverable.  The phrase that sticks in my mind, and that I'm sure was used over and over again, was "potentially implementable feature".  I'd have to say that, even today, I see "potentially implementable feature" as a far better guideline than "business value".

      First off, developers build features, not business value.  Business value comes from the implementation of the features, their integration into the business processes and a whole range of other considerations that, strictly speaking, are beyond control of the developers.  Expecting Scrum to somehow manage these other external factors is most probably going to be a failure, and extremely likely to lead to unnecessary complications inside of Scrum.

      Secondly, talking about "business value" seems to focus everyone's attention delivering something that the business can take and use, with some tangible benefit, each and every Sprint.  I don't think that was ever the intention of Scrum.  The idea is to iteratively and incrementally deliver something that eventually will be of business value, but not with any rule that each Sprint needs to deliver some of that business value.

      Personally, I think "potentially implementable feature" is a perfect definition of a deliverable.  A feature is...well...a feature.  Something that the user can perceive.  So this practically forces the idea that the development has to slice vertically through application.  A DAO to extract data from an obscure database is never going to count as a feature in a business process application, so you can't make it a Sprint deliverable by itself - it has to be part of something that is a feature.  User Stories are a great starting place to make sure that you features slice this way and mesh nicely with Scrum.

      There are lots of examples of "features" that have virtually no business value in and of themselves, and require the completion of other features to be "valuable".   We need to remember that this process is about building software, and incorporating the things that you (and the users) learn about the software as it's built.  It's not about creating a steady stream of new business value each Sprint.  It's great if you can deliver business value earlier, for sure, but I don't think even that needs to be a "rule" in Scrum.



      Dave Barrett


      This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please delete it and advise me (by return e-mail or otherwise) immediately.

      Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez le supprimer et m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.


    • frede_swe
      Dave, The Scrum Guide refers many time to value , i.e. but do not use the specific term business value . E.g. ...delivering products of the highest possible
      Message 2 of 30 , Jul 30, 2012
      • 0 Attachment
        Dave,

        The Scrum Guide refers many time to "value", i.e. but do not use the specific term "business value". E.g. "...delivering products of the highest possible value". It has been revised several times since you took your course. Is it hard to decide what has the highest value? Absolutely, but that's a different question.
        If you are only building features, how do you ensure that the features are things that are requested by your customers i.e. provide them with value? You could build a word processor and decide to add a feature to translate from Chinese to Latin. It's a feature, but does it provide any value to your customers, or are there other features that could provide _more_ value to your customers? Building a product with the wrong features will ultimately leave you with the wrong product.
        Also, the dev. team does not decide what to build, the product owner does. He/she may be influenced by the dev. team though.

        Fredrik


        --- In scrumdevelopment@yahoogroups.com, David A Barrett <dave.barrett@...> wrote:
        >
        > There's been a lot of discussion here lately about delivering "business
        > value" each Sprint, and I'm wondering if somehow we've lost track of the
        > underlying concepts of Scrum (at least in this respect), and are simply
        > getting caught in the trap of nit-picking about rules and definitions.
        > Loosing sight of forest for the trees, if you like.
        >
        > I don't recall that ten years ago, when I took the CSM course (taught back
        > then by Ken himself), any mention of "business value" as a Sprint
        > deliverable. The phrase that sticks in my mind, and that I'm sure was
        > used over and over again, was "potentially implementable feature". I'd
        > have to say that, even today, I see "potentially implementable feature" as
        > a far better guideline than "business value".
        >
        > First off, developers build features, not business value. Business value
        > comes from the implementation of the features, their integration into the
        > business processes and a whole range of other considerations that,
        > strictly speaking, are beyond control of the developers. Expecting Scrum
        > to somehow manage these other external factors is most probably going to
        > be a failure, and extremely likely to lead to unnecessary complications
        > inside of Scrum.
        >
        > Secondly, talking about "business value" seems to focus everyone's
        > attention delivering something that the business can take and use, with
        > some tangible benefit, each and every Sprint. I don't think that was ever
        > the intention of Scrum. The idea is to iteratively and incrementally
        > deliver something that eventually will be of business value, but not with
        > any rule that each Sprint needs to deliver some of that business value.
        >
        > Personally, I think "potentially implementable feature" is a perfect
        > definition of a deliverable. A feature is...well...a feature. Something
        > that the user can perceive. So this practically forces the idea that the
        > development has to slice vertically through application. A DAO to extract
        > data from an obscure database is never going to count as a feature in a
        > business process application, so you can't make it a Sprint deliverable by
        > itself - it has to be part of something that is a feature. User Stories
        > are a great starting place to make sure that you features slice this way
        > and mesh nicely with Scrum.
        >
        > There are lots of examples of "features" that have virtually no business
        > value in and of themselves, and require the completion of other features
        > to be "valuable". We need to remember that this process is about
        > building software, and incorporating the things that you (and the users)
        > learn about the software as it's built. It's not about creating a steady
        > stream of new business value each Sprint. It's great if you can deliver
        > business value earlier, for sure, but I don't think even that needs to be
        > a "rule" in Scrum.
        >
        >
        >
        > Dave Barrett
        >
        >
        > This e-mail may be privileged and/or confidential, and the sender does not
        > waive any related rights and obligations. Any distribution, use or copying
        > of this e-mail or the information it contains by other than an intended
        > recipient is unauthorized. If you received this e-mail in error, please
        > delete it and advise me (by return e-mail or otherwise) immediately.
        >
        > Ce courrier électronique est confidentiel et protégé. L'expéditeur ne
        > renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion,
        > utilisation ou copie de ce message ou des renseignements qu'il contient
        > par une personne autre que le (les) destinataire(s) désigné(s) est
        > interdite. Si vous recevez ce courrier électronique par erreur, veuillez
        > le supprimer et m'en aviser immédiatement, par retour de courrier
        > électronique ou par un autre moyen.
        >
      • Cheng, Richard
        Hello all, The DC Scrum User Group and Excella Consulting is bringing Sharon Bowman into the Washington DC area to give her 2 day training workshop. For those
        Message 3 of 30 , Aug 2, 2012
        • 0 Attachment
          Hello all,

          The DC Scrum User Group and Excella Consulting is bringing Sharon Bowman into the Washington DC area to give her 2 day training workshop.  For those not familiar with Sharon, she's essentially a trainer's trainer and has several great books, including Training from the Back of the Room! and Using Brain Science To Make Training Stick.  Her techniques focus on creating an interactive experiential learning environment.  

          I've been following Sharon for awhile and have been wanting to take her class.  As I'm on my Certified Scrum Trainer journey, all of the CSTs I've worked with keep referencing her work.  Unfortunately she no longer gives public courses, so Excella and the DCSUG are bringing her to us.  For anyone that is interested in becoming a training or becoming better as a trainer, this is a great opportunity to do so! The class will be using Agile training as a point of reference, but the training techniques really extend out to more than just the Agile domain.  For more information take a look at http://www.bowperson.com/.  You can signup for the class at http://how-to-be-an-agile-trainer.eventbrite.com/.  Between now and 8/17, you can use the code "EarlyBird" to receive a $300 discount on the class.  

          Apologies for the promo in the middle of the discussion group, but this is a really unique training experience I wanted to share. Feel free to share with your colleagues and friends.

          Cheers,
          ------------------------------
          Richard K Cheng, PMP, CSP
          Principal & Agile Center of Excellence, Lead
          Excella Consulting
          richard.cheng@... 
          703-967-8620
          twitter: @RichardKCheng

        • RonJeffries
          Cass and David, ... The notion of business value , borrowed from XP, reminds us that the backlog items implemented should be potentially shippable , in the
          Message 4 of 30 , Aug 3, 2012
          • 0 Attachment
            Cass and David,

            On Jul 28, 2012, at 7:41 PM, Cass Dalton <cassdalton73@...> wrote:

            That's a very interesting insight and is probably the part I've been getting confused about.  I believed that Scrum was supposed to be providing new customer value every sprint.  I think I have been overcompensating against the traditional model that doesn't try to provide customer value until the very end. And every time I'm looking to split features and don't end up with new customer value, I feel like my old waterfall mentality has slipped back in.

            The notion of "business value", borrowed from XP, reminds us that the backlog items implemented should be "potentially shippable", in the sense that they make sense to the Product Owner and would make sense to a customer. If at the Sprint Review, we have to explain that we beefed up the stored procedures this week, that was not a good backlog item.

            Best known practice today, in my opinion, is to do backlog items each of which makes sense to the Product Owner as a little bitty increment of visible feature value.

            My concern is that if we lose focus on that we'll start thinking that "clean up the crappy code in the Fubar module" is a perfectly good backlog item. It might be a backlog item, but it is far from perfectly good, IMO.

            Ron Jeffries
            I'm not bad, I'm just drawn that way.  -- Jessica Rabbit

          • Cass Dalton
            So how do you rationalize refactoring that only improves maintainability? I m sure there are refactoring efforts that can easily be tied to direct customer
            Message 5 of 30 , Aug 8, 2012
            • 0 Attachment
              So how do you rationalize refactoring that only improves maintainability?  I'm sure there are refactoring efforts that can easily be tied to direct customer value, but I would also think that there are refactoring efforts that really only improve the maintainability and readability of the code.  

              On Fri, Aug 3, 2012 at 4:03 PM, RonJeffries <ronjeffries@...> wrote:
               

              Cass and David,


              On Jul 28, 2012, at 7:41 PM, Cass Dalton <cassdalton73@...> wrote:

              That's a very interesting insight and is probably the part I've been getting confused about.  I believed that Scrum was supposed to be providing new customer value every sprint.  I think I have been overcompensating against the traditional model that doesn't try to provide customer value until the very end. And every time I'm looking to split features and don't end up with new customer value, I feel like my old waterfall mentality has slipped back in.

              The notion of "business value", borrowed from XP, reminds us that the backlog items implemented should be "potentially shippable", in the sense that they make sense to the Product Owner and would make sense to a customer. If at the Sprint Review, we have to explain that we beefed up the stored procedures this week, that was not a good backlog item.

              Best known practice today, in my opinion, is to do backlog items each of which makes sense to the Product Owner as a little bitty increment of visible feature value.

              My concern is that if we lose focus on that we'll start thinking that "clean up the crappy code in the Fubar module" is a perfectly good backlog item. It might be a backlog item, but it is far from perfectly good, IMO.

              Ron Jeffries
              I'm not bad, I'm just drawn that way.  -- Jessica Rabbit


            • RonJeffries
              Cass, ... What do you mean by rationalize, and when in the process is this question being asked? Ron Jeffries www.XProgramming.com If another does not intend
              Message 6 of 30 , Aug 9, 2012
              • 0 Attachment
                Cass,

                On Aug 8, 2012, at 1:32 PM, Cass Dalton <cassdalton73@...> wrote:

                So how do you rationalize refactoring that only improves maintainability?  I'm sure there are refactoring efforts that can easily be tied to direct customer value, but I would also think that there are refactoring efforts that really only improve the maintainability and readability of the code.  

                What do you mean by rationalize, and when in the process is this question being asked?

                Ron Jeffries
                If another does not intend offense, it is wrong for me to seek it;
                if another does indeed intend offense, it is foolish for me to permit it.
                  -- Kelly Easterley

              • Cass Dalton
                I know that rationalize implies a sort of falsifiation of the rationale but that was not my intention. My question is really about trying to reconcile the gap
                Message 7 of 30 , Aug 9, 2012
                • 0 Attachment
                  I know that rationalize implies a sort of falsifiation of the rationale but that was not my intention.  My question is really about trying to reconcile the gap between your suggestion that every "good" product backlog item should have direct customer value and you shouldn't have to be explaining that you "beefed up the stored procedures" and the idea that beefing up the stored procedures may generate value in the long term, but has no visible short term value (maybe I misunderstood your analogy).  They way I understood your post, you are arguing that every story should have value that is easily demonstrable to the customer.  But following that logic naively leads to never paying down technical debt that the product owner can't see.  I am not implying that that is what you were suggesting, I know you've been in the business long enough to know how to pay down your technical debt.  I'm just wondering how you suggest making the point to the PO that paying down the technical debt is valuble based on your statement,
                  'if we lose focus on that we'll start thinking that "clean up the crappy code in the Fubar module" is a perfectly good backlog item. It might be a backlog item, but it is far from perfectly good'

                  On Thu, Aug 9, 2012 at 2:18 PM, RonJeffries <ronjeffries@...> wrote:
                   

                  Cass,


                  On Aug 8, 2012, at 1:32 PM, Cass Dalton <cassdalton73@...> wrote:

                  So how do you rationalize refactoring that only improves maintainability?  I'm sure there are refactoring efforts that can easily be tied to direct customer value, but I would also think that there are refactoring efforts that really only improve the maintainability and readability of the code.  

                  What do you mean by rationalize, and when in the process is this question being asked?

                  Ron Jeffries
                  If another does not intend offense, it is wrong for me to seek it;
                  if another does indeed intend offense, it is foolish for me to permit it.
                    -- Kelly Easterley


                • barrettdab
                  ... That s not a potentially implementable feature under any circumstance that it can imagine. I like the focus on feature , because it pretty much demands
                  Message 8 of 30 , Aug 10, 2012
                  • 0 Attachment
                    > My concern is that if we lose focus on that we'll start thinking that
                    > "clean up the crappy code in the Fubar module" is a perfectly good backlog
                    > item.

                    That's not a "potentially implementable feature" under any circumstance that it can imagine.

                    I like the focus on "feature", because it pretty much demands that the effects on the system are something that a user can see.


                    --- In scrumdevelopment@yahoogroups.com, Cass Dalton <cassdalton73@...> wrote:
                    >
                    > So how do you rationalize refactoring that only improves maintainability?

                    You don't. It's not allowed.

                    Think about it. You're opening up working code and playing with it simply because at some unspecified time in the future you might have to change it for some legitimate reason and you want to make it easier then?

                    Scrum views refactoring as part of the cost of implementing a backlog item, not something that actually would included in the backlog as a separate item. It could, however, be listed as a task during a Sprint.

                    dave
                  • Cass Dalton
                    The XP refactoring process as it was described to me was 1) write a test, 2) write the simplest code to make the test pass, 3) once you have a passing test,
                    Message 9 of 30 , Aug 11, 2012
                    • 0 Attachment

                      The XP refactoring process as it was described to me was 1) write a test, 2) write the simplest code to make the test pass, 3) once you have a passing test, refactor the code to be the way you want it to be.  Is that incorrect?  If it is correct, does step 3 provide business value?

                      On Aug 10, 2012 9:23 AM, "barrettdab" <dave.barrett@...> wrote:
                       

                      > My concern is that if we lose focus on that we'll start thinking that
                      > "clean up the crappy code in the Fubar module" is a perfectly good backlog
                      > item.

                      That's not a "potentially implementable feature" under any circumstance that it can imagine.

                      I like the focus on "feature", because it pretty much demands that the effects on the system are something that a user can see.

                      --- In scrumdevelopment@yahoogroups.com, Cass Dalton <cassdalton73@...> wrote:
                      >
                      > So how do you rationalize refactoring that only improves maintainability?

                      You don't. It's not allowed.

                      Think about it. You're opening up working code and playing with it simply because at some unspecified time in the future you might have to change it for some legitimate reason and you want to make it easier then?

                      Scrum views refactoring as part of the cost of implementing a backlog item, not something that actually would included in the backlog as a separate item. It could, however, be listed as a task during a Sprint.

                      dave

                    • Adam Sroka
                      ... Almost. Instead of refactoring to the way you want it to be, try refactoring to these qualities: 1) passes all the tests 2) contains no duplication 3)
                      Message 10 of 30 , Aug 16, 2012
                      • 0 Attachment
                        On Sat, Aug 11, 2012 at 3:14 PM, Cass Dalton <cassdalton73@...> wrote:
                        >
                        >
                        >
                        > The XP refactoring process as it was described to me was 1) write a test,
                        > 2) write the simplest code to make the test pass, 3) once you have a passing
                        > test, refactor the code to be the way you want it to be. Is that incorrect?
                        > If it is correct, does step 3 provide business value?
                        >

                        Almost. Instead of refactoring to the way you want it to be, try
                        refactoring to these qualities:

                        1) passes all the tests
                        2) contains no duplication
                        3) clearly expresses intent
                        4) has no superfluous parts

                        If you refactor to some other set of qualities that you like, you may
                        end up with code that is hard to maintain. The following qualities are
                        root causes of maintenance problems:

                        1) untested code
                        2) duplication
                        3) obfuscation
                        4) superfluous parts

                        > On Aug 10, 2012 9:23 AM, "barrettdab" <dave.barrett@...> wrote:
                        >>
                        >>
                        >>
                        >> > My concern is that if we lose focus on that we'll start thinking that
                        >> > "clean up the crappy code in the Fubar module" is a perfectly good
                        >> > backlog
                        >> > item.
                        >>
                        >> That's not a "potentially implementable feature" under any circumstance
                        >> that it can imagine.
                        >>
                        >> I like the focus on "feature", because it pretty much demands that the
                        >> effects on the system are something that a user can see.
                        >>
                        >> --- In scrumdevelopment@yahoogroups.com, Cass Dalton <cassdalton73@...>
                        >> wrote:
                        >> >
                        >> > So how do you rationalize refactoring that only improves
                        >> > maintainability?
                        >>
                        >> You don't. It's not allowed.
                        >>
                        >> Think about it. You're opening up working code and playing with it simply
                        >> because at some unspecified time in the future you might have to change it
                        >> for some legitimate reason and you want to make it easier then?
                        >>
                        >> Scrum views refactoring as part of the cost of implementing a backlog
                        >> item, not something that actually would included in the backlog as a
                        >> separate item. It could, however, be listed as a task during a Sprint.
                        >>
                        >> dave
                        >>
                        >
                      • RonJeffries
                        Cass ... stepping in, ... Yes. That is the best way to do things. For the best teams, every story has visible business value, and is typically a feature. ...
                        Message 11 of 30 , Aug 16, 2012
                        • 0 Attachment
                          Cass ... stepping in,

                          On Aug 9, 2012, at 2:50 PM, Cass Dalton <cassdalton73@...> wrote:

                          They way I understood your post, you are arguing that every story should have value that is easily demonstrable to the customer.  

                          Yes. That is the best way to do things. For the best teams, every story has visible business value, and is typically a feature. 

                          But following that logic naively leads to never paying down technical debt that the product owner can't see.

                          It does not need to lead to that. However, "pay down technical debt" or "refactor the Fubar" or "write more tests for the Mumble" are never stories for the best teams. The best teams behave as if there is no such thing as a "technical story".

                          Now ... have you a followup question or two?

                          Ron Jeffries
                          www.XProgramming.com
                          There's no word for accountability in Finnish. 
                          Accountability is something that is left when responsibility has been subtracted. 
                          --Pasi Sahlberg

                        • Cass Dalton
                          Lets say the Fubar needs refactoring (code duplication, clumsy and confusing logic, etc) but it and all of the modules that interact with it are operating to
                          Message 12 of 30 , Aug 17, 2012
                          • 0 Attachment
                            Lets say the Fubar needs refactoring (code duplication, clumsy and confusing logic, etc) but it and all of the modules that interact with it are operating to within the PO's parameters.  Do you just leave it?

                            On Thu, Aug 16, 2012 at 9:33 PM, RonJeffries <ronjeffries@...> wrote:
                             

                            Cass ... stepping in,


                            On Aug 9, 2012, at 2:50 PM, Cass Dalton <cassdalton73@...> wrote:

                            They way I understood your post, you are arguing that every story should have value that is easily demonstrable to the customer.  

                            Yes. That is the best way to do things. For the best teams, every story has visible business value, and is typically a feature. 

                            But following that logic naively leads to never paying down technical debt that the product owner can't see.

                            It does not need to lead to that. However, "pay down technical debt" or "refactor the Fubar" or "write more tests for the Mumble" are never stories for the best teams. The best teams behave as if there is no such thing as a "technical story".

                            Now ... have you a followup question or two?

                            Ron Jeffries
                            www.XProgramming.com
                            There's no word for accountability in Finnish. 
                            Accountability is something that is left when responsibility has been subtracted. 
                            --Pasi Sahlberg


                          • Jesse Houwing
                            We see it as. it isn t done-done until ir s neat and tidy. so the business value isn t truly provided until it is.
                            Message 13 of 30 , Aug 18, 2012
                            • 0 Attachment
                              We see it as. it isn't done-done until ir's neat and tidy. so the business value isn't truly provided until it is.

                              On Sun, Aug 12, 2012 at 12:14 AM, Cass Dalton <cassdalton73@...> wrote:


                              The XP refactoring process as it was described to me was 1) write a test, 2) write the simplest code to make the test pass, 3) once you have a passing test, refactor the code to be the way you want it to be.  Is that incorrect?  If it is correct, does step 3 provide business value?

                              On Aug 10, 2012 9:23 AM, "barrettdab" <dave.barrett@...> wrote:
                               

                              > My concern is that if we lose focus on that we'll start thinking that
                              > "clean up the crappy code in the Fubar module" is a perfectly good backlog
                              > item.

                              That's not a "potentially implementable feature" under any circumstance that it can imagine.

                              I like the focus on "feature", because it pretty much demands that the effects on the system are something that a user can see.

                              --- In scrumdevelopment@yahoogroups.com, Cass Dalton <cassdalton73@...> wrote:
                              >
                              > So how do you rationalize refactoring that only improves maintainability?

                              You don't. It's not allowed.

                              Think about it. You're opening up working code and playing with it simply because at some unspecified time in the future you might have to change it for some legitimate reason and you want to make it easier then?

                              Scrum views refactoring as part of the cost of implementing a backlog item, not something that actually would included in the backlog as a separate item. It could, however, be listed as a task during a Sprint.

                              dave




                            • RonJeffries
                              Hi Cass, ... In order to answer, I must know: Do you mean that it is just sitting there not being edited? Or are we making changes that involve it? And, more
                              Message 14 of 30 , Aug 22, 2012
                              • 0 Attachment
                                Hi Cass,

                                On Aug 17, 2012, at 8:29 AM, Cass Dalton <cassdalton73@...> wrote:

                                Lets say the Fubar needs refactoring (code duplication, clumsy and confusing logic, etc) but it and all of the modules that interact with it are operating to within the PO's parameters.  Do you just leave it?

                                In order to answer, I must know:
                                Do you mean that it is just sitting there not being edited? Or are we making changes that involve it?

                                And, more important in some ways, what have been been doing that lets our code get that way?

                                Ron Jeffries
                                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?

                              • Charles Bradley - Scrum Coach CSP CSM PSM
                                Ron, (I don t mean to interrupt or hijack). Do you have your views on technical debt in something that is published?  I would love to see that as I think it s
                                Message 15 of 30 , Aug 22, 2012
                                • 0 Attachment
                                  Ron,

                                  (I don't mean to interrupt or hijack).

                                  Do you have your views on technical debt in something that is published?  I would love to see that as I think it's a view that does not get enough attention in the industry.
                                   
                                  -------
                                  Charles Bradley
                                  http://www.ScrumCrazy.com




                                  From: RonJeffries <ronjeffries@...>
                                  To: scrumdevelopment@yahoogroups.com
                                  Sent: Wednesday, August 22, 2012 10:56 AM
                                  Subject: Re: [scrumdevelopment] "Business Value" v. "Potentially Implementable Feature"



                                  Hi Cass,

                                  On Aug 17, 2012, at 8:29 AM, Cass Dalton <cassdalton73@...> wrote:

                                  Lets say the Fubar needs refactoring (code duplication, clumsy and confusing logic, etc) but it and all of the modules that interact with it are operating to within the PO's parameters.  Do you just leave it?

                                  In order to answer, I must know:
                                  Do you mean that it is just sitting there not being edited? Or are we making changes that involve it?

                                  And, more important in some ways, what have been been doing that lets our code get that way?

                                  Ron Jeffries
                                  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?





                                • RonJeffries
                                  Charles, ... Let me put them right here. If anyone doesn t find them quite obvious and clear, please inquire. Never give code to the Product Owner that is not
                                  Message 16 of 30 , Aug 22, 2012
                                  • 0 Attachment
                                    Charles,

                                    On Aug 22, 2012, at 1:24 PM, Charles Bradley - Scrum Coach CSP CSM PSM I <chuck-lists2@...> wrote:

                                    Do you have your views on technical debt in something that is published?  I would love to see that as I think it's a view that does not get enough attention in the industry.

                                    Let me put them right here. If anyone doesn't find them quite obvious and clear, please inquire.

                                    Never give code to the Product Owner that is not well programmed. This means clear code, well factored, supported by sufficient tests to be sure that it works.

                                    If we are later going to look at this code and say that it sucks, it is not clear, well factored and supported by sufficient tests right now. 

                                    If we do not know what clear, well factored code, supported by tests looks like, find out. We are cheating our team, our Product Owner, and ourselves.

                                    When we do give code to the Product Owner that is not clear, well factored, and supported by tests, know that we have done a bad thing. There is some reason for that. This is a top priority for our next Retrospective. Figure out why we are doing bad work and fix it. Stop doing bad work.

                                    P.S. There is no tradeoff against this kind of quality. We cannot go faster by skimping on clear well factored code supported by tests. It will bite us in the ass. You wouldn't be reading this answer if it wasn't already biting you in the ass. Stop writing bad code.

                                    OK, despite our best efforts, we turn out to be incompetent. We now have code in the system that isn't clear, well factored, and supported by enough tests. Perhaps we just noticed. Perhaps we have learned some stuff that we wish we had known sooner. Perhaps we bent under pressure. Doesn't matter. We do a Retrospective and figure out what caused it, and remove the cause. But the existing code is still bad. What do we do?

                                    We do not, repeat DO NOT, put code improvement "stories" in the Product Backlog. The main reason for this is that we cannot state the value of the improvement in any terms that the Product Owner can understand, and therefore the Product Owner can never schedule the stories. P.S. We don't know the value either.

                                    If we do put code improvement stories in the backlog, we can't count the work against our Product Burndown or other progress measurements.  Why not? Because we have already been paid for this work when we did it badly last time. We don't pay the mechanic again when he re-fixes the far. We don't pay the programmer again when he fixes what he did poorly last time. Anyway, don't schedule this work as stories in the backlog anyway. It's just wrong. Stop it.

                                    Then what do we do about this bad code? I'm glad you asked.

                                    If our Product Owner's stories do not cause us to make changes to the bad code, we leave it alone. It is not hurting anyone, and it will not rot. It will just sit there. Cleaning it up will take time away from stories, and it will pay off, if it ever does, an unknown amount at an unknown time in the future. Bad investment. 

                                    If stories cause us to work in the bad code, the bad code will slow us down. It will make us throw up, causing extra breaks in the rest room. We will be sad. Therefore, follow the "Boy Scount Rule", "Always leave the campground cleaner than you found it". Clean up the code in a reasonable fashion. Do not take ten days to rewrite it. We don't know how and anyway it's inefficient. Just leave it better than it was. Over time, all the code that is troubling us will get better. 

                                    That is all:
                                    • Don't do it. 
                                    • When we do it, figure out why and stop. 
                                    • When we do it, leave it alone if it's not in the way. 
                                    • If it is in the way, clean up the parts we pass through.

                                    You may be wondering "How do we get the time to keep it clean? How do we get the time to improve the campground?"

                                    We have a story to do. That story includes a certain amount of experimenting to figure it out. It includes enough testing to leave the code properly tested. It includes the time to make the code clean and well factored, including any code we have to touch to do the story. 

                                    That's how much time the story takes. So, that's how much time we take to do it. If we take less time, we have just stuck a screwdriver into one of our own bodily orifices. Stop doing that. You'll get a rash.


                                    So. Any followup questions?

                                    Ron Jeffries
                                    If another does not intend offense, it is wrong for me to seek it;
                                    if another does indeed intend offense, it is foolish for me to permit it.
                                      -- Kelly Easterley

                                  • Charles Bradley - Scrum Coach CSP CSM PSM
                                    Ron, Brilliant.  Just brilliant!  Thanks so much for posting.  I wish that you would publish it somewhere on a web site or book or something, but I will
                                    Message 17 of 30 , Aug 22, 2012
                                    • 0 Attachment
                                      Ron,

                                      Brilliant.  Just brilliant!  Thanks so much for posting.  I wish that you would publish it somewhere on a web site or book or something, but I will keep this post very handy for when I need it. 

                                      The only thing I might suggest adding is some small amount of clarification that poorly programmed code is not the same as code with defects, and thus code with defects requires a different approach.
                                       
                                      -------
                                      Charles Bradley
                                      http://www.ScrumCrazy.com




                                      From: RonJeffries <ronjeffries@...>
                                      To: scrumdevelopment@yahoogroups.com
                                      Sent: Wednesday, August 22, 2012 12:23 PM
                                      Subject: Re: [scrumdevelopment] "Business Value" v. "Potentially Implementable Feature"



                                      Charles,

                                      On Aug 22, 2012, at 1:24 PM, Charles Bradley - Scrum Coach CSP CSM PSM I <chuck-lists2@...> wrote:

                                      Do you have your views on technical debt in something that is published?  I would love to see that as I think it's a view that does not get enough attention in the industry.

                                      Let me put them right here. If anyone doesn't find them quite obvious and clear, please inquire.

                                      Never give code to the Product Owner that is not well programmed. This means clear code, well factored, supported by sufficient tests to be sure that it works.

                                      If we are later going to look at this code and say that it sucks, it is not clear, well factored and supported by sufficient tests right now. 

                                      If we do not know what clear, well factored code, supported by tests looks like, find out. We are cheating our team, our Product Owner, and ourselves.

                                      When we do give code to the Product Owner that is not clear, well factored, and supported by tests, know that we have done a bad thing. There is some reason for that. This is a top priority for our next Retrospective. Figure out why we are doing bad work and fix it. Stop doing bad work.

                                      P.S. There is no tradeoff against this kind of quality. We cannot go faster by skimping on clear well factored code supported by tests. It will bite us in the ass. You wouldn't be reading this answer if it wasn't already biting you in the ass. Stop writing bad code.

                                      OK, despite our best efforts, we turn out to be incompetent. We now have code in the system that isn't clear, well factored, and supported by enough tests. Perhaps we just noticed. Perhaps we have learned some stuff that we wish we had known sooner. Perhaps we bent under pressure. Doesn't matter. We do a Retrospective and figure out what caused it, and remove the cause. But the existing code is still bad. What do we do?

                                      We do not, repeat DO NOT, put code improvement "stories" in the Product Backlog. The main reason for this is that we cannot state the value of the improvement in any terms that the Product Owner can understand, and therefore the Product Owner can never schedule the stories. P.S. We don't know the value either.

                                      If we do put code improvement stories in the backlog, we can't count the work against our Product Burndown or other progress measurements.  Why not? Because we have already been paid for this work when we did it badly last time. We don't pay the mechanic again when he re-fixes the far. We don't pay the programmer again when he fixes what he did poorly last time. Anyway, don't schedule this work as stories in the backlog anyway. It's just wrong. Stop it.

                                      Then what do we do about this bad code? I'm glad you asked.

                                      If our Product Owner's stories do not cause us to make changes to the bad code, we leave it alone. It is not hurting anyone, and it will not rot. It will just sit there. Cleaning it up will take time away from stories, and it will pay off, if it ever does, an unknown amount at an unknown time in the future. Bad investment. 

                                      If stories cause us to work in the bad code, the bad code will slow us down. It will make us throw up, causing extra breaks in the rest room. We will be sad. Therefore, follow the "Boy Scount Rule", "Always leave the campground cleaner than you found it". Clean up the code in a reasonable fashion. Do not take ten days to rewrite it. We don't know how and anyway it's inefficient. Just leave it better than it was. Over time, all the code that is troubling us will get better. 

                                      That is all:
                                      • Don't do it. 
                                      • When we do it, figure out why and stop. 
                                      • When we do it, leave it alone if it's not in the way. 
                                      • If it is in the way, clean up the parts we pass through.

                                      You may be wondering "How do we get the time to keep it clean? How do we get the time to improve the campground?"

                                      We have a story to do. That story includes a certain amount of experimenting to figure it out. It includes enough testing to leave the code properly tested. It includes the time to make the code clean and well factored, including any code we have to touch to do the story. 

                                      That's how much time the story takes. So, that's how much time we take to do it. If we take less time, we have just stuck a screwdriver into one of our own bodily orifices. Stop doing that. You'll get a rash.


                                      So. Any followup questions?

                                      Ron Jeffries
                                      If another does not intend offense, it is wrong for me to seek it;
                                      if another does indeed intend offense, it is foolish for me to permit it.
                                        -- Kelly Easterley





                                    • Adam Sroka
                                      Hi Charles: I agree with what Ron says above, but let me give you a slightly different take and see if it helps: In TDD we refactor towards a Simple Design.
                                      Message 18 of 30 , Aug 22, 2012
                                      • 0 Attachment
                                        Hi Charles: 

                                        I agree with what Ron says above, but let me give you a slightly different take and see if it helps:

                                        In TDD we refactor towards a Simple Design. Simple Design was defined by Kent Beck as a design having these qualities:

                                        1) Passes all the tests (i.e. does what the PO wants)
                                        2) Contains no duplication
                                        3) Clearly communicates the author's intent
                                        4) Has no superfluous parts

                                        As Agile developers we value the ability to safely and rapidly make changes to a codebase in order to reflect our current understanding of the product and our customer's evolving needs. Simple Design makes this relatively easy. We just add or modify tests and then refactor mercillessly until we are satisfied that we still have a Simple Design. 

                                        Technical debt can mean a number of things and I find discussing it with people difficult. So, I take a slightly different tac nowadays. Instead I talk about safety. 

                                        If we don't refactor mercilessly to a simple design we eventually slip into maintenance mode. Maintenance mode is where good programmers go to die. More explicitly, code is hard to maintain when it exhibits any of the following properties: 

                                        1) Untested
                                        2) Contains duplication
                                        3) Obfuscated
                                        4) Has superfluous parts (often in the form of Speculative Generality) 

                                        This code is unsafe and must be fixed. Your life will be much simpler if you learn to work in a way that addresses these issues prior to the end of each Sprint. I have seen teams be successful carrying a limited amount of this crap from Sprint to Sprint, but IMNSHO even the best XP programmers I know don't get away with it as well as they think they do. 

                                        Hope that helps,
                                        Adam
                                      • Cass Dalton
                                        If you don t mind, I think I m going to put that post on a wall at work
                                        Message 19 of 30 , Aug 22, 2012
                                        • 0 Attachment

                                          If you don't mind, I think I'm going to put that post on a wall at work

                                          On Aug 22, 2012 2:24 PM, "RonJeffries" <ronjeffries@...> wrote:
                                           

                                          Charles,


                                          On Aug 22, 2012, at 1:24 PM, Charles Bradley - Scrum Coach CSP CSM PSM I <chuck-lists2@...> wrote:

                                          Do you have your views on technical debt in something that is published?  I would love to see that as I think it's a view that does not get enough attention in the industry.

                                          Let me put them right here. If anyone doesn't find them quite obvious and clear, please inquire.

                                          Never give code to the Product Owner that is not well programmed. This means clear code, well factored, supported by sufficient tests to be sure that it works.

                                          If we are later going to look at this code and say that it sucks, it is not clear, well factored and supported by sufficient tests right now. 

                                          If we do not know what clear, well factored code, supported by tests looks like, find out. We are cheating our team, our Product Owner, and ourselves.

                                          When we do give code to the Product Owner that is not clear, well factored, and supported by tests, know that we have done a bad thing. There is some reason for that. This is a top priority for our next Retrospective. Figure out why we are doing bad work and fix it. Stop doing bad work.

                                          P.S. There is no tradeoff against this kind of quality. We cannot go faster by skimping on clear well factored code supported by tests. It will bite us in the ass. You wouldn't be reading this answer if it wasn't already biting you in the ass. Stop writing bad code.

                                          OK, despite our best efforts, we turn out to be incompetent. We now have code in the system that isn't clear, well factored, and supported by enough tests. Perhaps we just noticed. Perhaps we have learned some stuff that we wish we had known sooner. Perhaps we bent under pressure. Doesn't matter. We do a Retrospective and figure out what caused it, and remove the cause. But the existing code is still bad. What do we do?

                                          We do not, repeat DO NOT, put code improvement "stories" in the Product Backlog. The main reason for this is that we cannot state the value of the improvement in any terms that the Product Owner can understand, and therefore the Product Owner can never schedule the stories. P.S. We don't know the value either.

                                          If we do put code improvement stories in the backlog, we can't count the work against our Product Burndown or other progress measurements.  Why not? Because we have already been paid for this work when we did it badly last time. We don't pay the mechanic again when he re-fixes the far. We don't pay the programmer again when he fixes what he did poorly last time. Anyway, don't schedule this work as stories in the backlog anyway. It's just wrong. Stop it.

                                          Then what do we do about this bad code? I'm glad you asked.

                                          If our Product Owner's stories do not cause us to make changes to the bad code, we leave it alone. It is not hurting anyone, and it will not rot. It will just sit there. Cleaning it up will take time away from stories, and it will pay off, if it ever does, an unknown amount at an unknown time in the future. Bad investment. 

                                          If stories cause us to work in the bad code, the bad code will slow us down. It will make us throw up, causing extra breaks in the rest room. We will be sad. Therefore, follow the "Boy Scount Rule", "Always leave the campground cleaner than you found it". Clean up the code in a reasonable fashion. Do not take ten days to rewrite it. We don't know how and anyway it's inefficient. Just leave it better than it was. Over time, all the code that is troubling us will get better. 

                                          That is all:
                                          • Don't do it. 
                                          • When we do it, figure out why and stop. 
                                          • When we do it, leave it alone if it's not in the way. 
                                          • If it is in the way, clean up the parts we pass through.

                                          You may be wondering "How do we get the time to keep it clean? How do we get the time to improve the campground?"

                                          We have a story to do. That story includes a certain amount of experimenting to figure it out. It includes enough testing to leave the code properly tested. It includes the time to make the code clean and well factored, including any code we have to touch to do the story. 

                                          That's how much time the story takes. So, that's how much time we take to do it. If we take less time, we have just stuck a screwdriver into one of our own bodily orifices. Stop doing that. You'll get a rash.


                                          So. Any followup questions?

                                          Ron Jeffries
                                          If another does not intend offense, it is wrong for me to seek it;
                                          if another does indeed intend offense, it is foolish for me to permit it.
                                            -- Kelly Easterley

                                        • Charles Bradley - Scrum Coach CSP CSM PSM
                                          Adam, Well said as well.  I think I have a very good idea of the viewpoint(which I attribute to Ron, mostly because I ve heard the viewpoint most often from
                                          Message 20 of 30 , Aug 22, 2012
                                          • 0 Attachment
                                            Adam,

                                            Well said as well. 

                                            I think I have a very good idea of the viewpoint(which I attribute to Ron, mostly because I've heard the viewpoint most often from him).  My question was more along the lines of where can I point people to read more about the view in a slightly more "published" resource?  Even Ron's blog/web site would work, but I try to not tell Ron how to live his life.  I just beg him to publish his (often genius, IMNSHO) views from time to time.  :-)

                                            At Agile2012 last week, I did finally have a chance to meet Ron and thank him in person for all of his work in the community.  I even lofted a (fairly) softball question to him in a Q&A session.  I plan to blog about it later this week and let Ron correct my recollection.  :-)

                                            (As an aside, Ron mentioned the Kent Beck Simple Design principles in his answer)

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




                                            From: Adam Sroka <adam.sroka@...>
                                            To: scrumdevelopment@yahoogroups.com
                                            Sent: Wednesday, August 22, 2012 12:46 PM
                                            Subject: Re: [scrumdevelopment] "Business Value" v. "Potentially Implementable Feature"



                                            Hi Charles: 

                                            I agree with what Ron says above, but let me give you a slightly different take and see if it helps:

                                            In TDD we refactor towards a Simple Design. Simple Design was defined by Kent Beck as a design having these qualities:

                                            1) Passes all the tests (i.e. does what the PO wants)
                                            2) Contains no duplication
                                            3) Clearly communicates the author's intent
                                            4) Has no superfluous parts

                                            As Agile developers we value the ability to safely and rapidly make changes to a codebase in order to reflect our current understanding of the product and our customer's evolving needs. Simple Design makes this relatively easy. We just add or modify tests and then refactor mercillessly until we are satisfied that we still have a Simple Design. 

                                            Technical debt can mean a number of things and I find discussing it with people difficult. So, I take a slightly different tac nowadays. Instead I talk about safety. 

                                            If we don't refactor mercilessly to a simple design we eventually slip into maintenance mode. Maintenance mode is where good programmers go to die. More explicitly, code is hard to maintain when it exhibits any of the following properties: 

                                            1) Untested
                                            2) Contains duplication
                                            3) Obfuscated
                                            4) Has superfluous parts (often in the form of Speculative Generality) 

                                            This code is unsafe and must be fixed. Your life will be much simpler if you learn to work in a way that addresses these issues prior to the end of each Sprint. I have seen teams be successful carrying a limited amount of this crap from Sprint to Sprint, but IMNSHO even the best XP programmers I know don't get away with it as well as they think they do. 

                                            Hope that helps,
                                            Adam




                                          • RonJeffries
                                            Adam, ... I agree. Once the code is bad enough to slow you down, you ll likely never get it back. Ron Jeffrieswww.XProgramming.com I try to Zen through it and
                                            Message 21 of 30 , Aug 22, 2012
                                            • 0 Attachment
                                              Adam,

                                              On Aug 22, 2012, at 2:46 PM, Adam Sroka <adam.sroka@...> wrote:

                                              I have seen teams be successful carrying a limited amount of this crap from Sprint to Sprint, but IMNSHO even the best XP programmers I know don't get away with it as well as they think they do. 

                                              I agree. Once the code is bad enough to slow you down, you'll likely never get it back.

                                              Ron Jeffries
                                              www.XProgramming.com
                                              I try to Zen through it and keep my voice very mellow and low.
                                              Inside I am screaming and have a machine gun.
                                              Yin and Yang I figure.
                                                -- Tom Jeffries

                                            • strazhce
                                              Hi, Chrales, I ve humbly copied Ron s post and Adam s response to Agile Skills Wiki:
                                              Message 22 of 30 , Aug 23, 2012
                                              • 0 Attachment
                                                Hi, Chrales,

                                                I've humbly copied Ron's post and Adam's response to Agile Skills Wiki:
                                                https://sites.google.com/site/agileskillsprojectwiki/collected-knowledge/ideas-to-refine/how-to-handle-technical-debt

                                                I do that sometimes and I find this helped me once or twice.
                                                I hope authors don't mind.

                                                Oleg

                                                --- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach CSP CSM PSM I <chuck-lists2@...> wrote:
                                                >
                                                > Ron,
                                                >
                                                > Brilliant.  Just brilliant!  Thanks so much for posting.  I wish that you would publish it somewhere on a web site or book or something, but I will keep this post very handy for when I need it. 
                                                >
                                                > The only thing I might suggest adding is some small amount of clarification that poorly programmed code is not the same as code with defects, and thus code with defects requires a different approach.
                                                >  
                                                >
                                                > -------
                                                > Charles Bradley
                                                > http://www.ScrumCrazy.com
                                                >
                                                >
                                                >
                                                >
                                                >
                                                > >________________________________
                                                > > From: RonJeffries <ronjeffries@...>
                                                > >To: scrumdevelopment@yahoogroups.com
                                                > >Sent: Wednesday, August 22, 2012 12:23 PM
                                                > >Subject: Re: [scrumdevelopment] "Business Value" v. "Potentially Implementable Feature"
                                                > >
                                                > >
                                                > >
                                                > >
                                                > >
                                                > >Charles,
                                                > >
                                                > >
                                                > >On Aug 22, 2012, at 1:24 PM, Charles Bradley - Scrum Coach CSP CSM PSM I <chuck-lists2@...> wrote:
                                                > >
                                                > >Do you have your views on technical debt in something that is published?  I would love to see that as I think it's a view that does not get enough attention in the industry.
                                                > >
                                                > >Let me put them right here. If anyone doesn't find them quite obvious and clear, please inquire.
                                                > >
                                                > >
                                                > >Never give code to the Product Owner that is not well programmed. This means clear code, well factored, supported by sufficient tests to be sure that it works.
                                                > >
                                                > >
                                                > >If we are later going to look at this code and say that it sucks, it is not clear, well factored and supported by sufficient tests right now. 
                                                > >>
                                                > >>
                                                > >>If we do not know what clear, well factored code, supported by tests looks like, find out. We are cheating our team, our Product Owner, and ourselves.
                                                > >>
                                                > >>
                                                > >>When we do give code to the Product Owner that is not clear, well factored, and supported by tests, know that we have done a bad thing. There is some reason for that. This is a top priority for our next Retrospective. Figure out why we are doing bad work and fix it. Stop doing bad work.
                                                > >>
                                                > >>
                                                > >>P.S. There is no tradeoff against this kind of quality. We cannot go faster by skimping on clear well factored code supported by tests. It will bite us in the ass. You wouldn't be reading this answer if it wasn't already biting you in the ass. Stop writing bad code.
                                                > >>
                                                > >>OK, despite our best efforts, we turn out to be incompetent. We now have code in the system that isn't clear, well factored, and supported by enough tests. Perhaps we just noticed. Perhaps we have learned some stuff that we wish we had known sooner. Perhaps we bent under pressure. Doesn't matter. We do a Retrospective and figure out what caused it, and remove the cause. But the existing code is still bad. What do we do?
                                                > >
                                                > >
                                                > >We do not, repeat DO NOT, put code improvement "stories" in the Product Backlog. The main reason for this is that we cannot state the value of the improvement in any terms that the Product Owner can understand, and therefore the Product Owner can never schedule the stories. P.S. We don't know the value either.
                                                > >
                                                > >
                                                > >If we do put code improvement stories in the backlog, we can't count the work against our Product Burndown or other progress measurements.  Why not? Because we have already been paid for this work when we did it badly last time. We don't pay the mechanic again when he re-fixes the far. We don't pay the programmer again when he fixes what he did poorly last time. Anyway, don't schedule this work as stories in the backlog anyway. It's just wrong. Stop it.
                                                > >
                                                > >
                                                > >Then what do we do about this bad code? I'm glad you asked.
                                                > >
                                                > >
                                                > >If our Product Owner's stories do not cause us to make changes to the bad code, we leave it alone. It is not hurting anyone, and it will not rot. It will just sit there. Cleaning it up will take time away from stories, and it will pay off, if it ever does, an unknown amount at an unknown time in the future. Bad investment. 
                                                > >
                                                > >
                                                > >If stories cause us to work in the bad code, the bad code will slow us down. It will make us throw up, causing extra breaks in the rest room. We will be sad. Therefore, follow the "Boy Scount Rule", "Always leave the campground cleaner than you found it". Clean up the code in a reasonable fashion. Do not take ten days to rewrite it. We don't know how and anyway it's inefficient. Just leave it better than it was. Over time, all the code that is troubling us will get better. 
                                                > >
                                                > >
                                                > >That is all:
                                                > > * Don't do it. 
                                                > > * When we do it, figure out why and stop. 
                                                > > * When we do it, leave it alone if it's not in the way. 
                                                > > * If it is in the way, clean up the parts we pass through.
                                                > >
                                                > >
                                                > >You may be wondering "How do we get the time to keep it clean? How do we get the time to improve the campground?"
                                                > >
                                                > >
                                                > >We have a story to do. That story includes a certain amount of experimenting to figure it out. It includes enough testing to leave the code properly tested. It includes the time to make the code clean and well factored, including any code we have to touch to do the story. 
                                                > >
                                                > >
                                                > >That's how much time the story takes. So, that's how much time we take to do it. If we take less time, we have just stuck a screwdriver into one of our own bodily orifices. Stop doing that. You'll get a rash.
                                                > >>
                                                > >>
                                                > >
                                                > >So. Any followup questions?
                                                > >
                                                > >
                                                > >Ron Jeffries
                                                > >www.XProgramming.com
                                                > >If another does not intend offense, it is wrong for me to seek it;
                                                > >if another does indeed intend offense, it is foolish for me to permit it.
                                                > >  -- Kelly Easterley
                                                > >
                                                > >
                                                > >
                                                > >
                                                > >
                                                > >
                                                >
                                              • RonJeffries
                                                Hi Charles, ... Hm, in what way? Should the team randomly fix defects in code they re not working on as part of the Sprint? I don t think so. Should they fix
                                                Message 23 of 30 , Aug 23, 2012
                                                • 0 Attachment
                                                  Hi Charles,

                                                  On Aug 22, 2012, at 2:41 PM, Charles Bradley - Scrum Coach CSP CSM PSM I <chuck-lists2@...> wrote:

                                                  The only thing I might suggest adding is some small amount of clarification that poorly programmed code is not the same as code with defects, and thus code with defects requires a different approach.

                                                  Hm, in what way? 

                                                  Should the team randomly fix defects in code they're not working on as part of the Sprint? I don't think so. 

                                                  Should they fix them as part of cleaning the code they're working on? I would say yes.

                                                  When defects occur, I recommend scheduling the fixes just like any other story. And, of course, retrospecting to see what caused the issue and how to avoid it in the future.


                                                  And we have not addressed at all what a team should do "in their free time". 

                                                  Ron Jeffries
                                                  If another does not intend offense, it is wrong for me to seek it;
                                                  if another does indeed intend offense, it is foolish for me to permit it.
                                                    -- Kelly Easterley

                                                • Charles Bradley - Scrum Coach CSP CSM PSM
                                                  ... requires ... I was thinking something like: * When defects occur, I recommend scheduling the fixes just like any other story. * Does this include
                                                  Message 24 of 30 , Aug 23, 2012
                                                  • 0 Attachment

                                                    > suggest adding is some small amount of clarification that poorly programmed
                                                    > code is not the same as code with defects, and thus code with defects requires
                                                    > a different approach.

                                                    >>Hm, in what way?

                                                    I was thinking something like:
                                                    • >> When defects occur, I recommend scheduling the fixes just like any other story.
                                                      • Does this include assigning story points?  I don't think you would approve of that in some cases-- worth clarifying IMO
                                                    • While poorly programmed code (without defects) still provides the business value of the feature, code with defects does not provide the related business value of the feature defected.  In some ways, defects *decrease* business value if only from the mere frustration of a user encountering that defect.
                                                    • Maybe make a distinction between work in progress defects vs. existing/legacy defects
                                                    My main point was that dealing with defects is not exactly the same as dealing with technical debt, but there are a LOT (and I mean A LOT!) of people out there who lump defects in as being "technical debt," and my suspicion is that those same people will assume that "poorly programmed code" includes "code with defects."

                                                    The "in their free time" thing is also worthy of an article/thread by itself, though I wonder what exactly you mean by that.  Maybe a convo for another time or thread.  We're already pretty far afield of the subject line.

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




                                                    From: RonJeffries <ronjeffries@...>
                                                    To: scrumdevelopment@yahoogroups.com
                                                    Sent: Thursday, August 23, 2012 3:47 AM
                                                    Subject: Re: [scrumdevelopment] "Business Value" v. "Potentially Implementable Feature"



                                                    Hi Charles,

                                                    On Aug 22, 2012, at 2:41 PM, Charles Bradley - Scrum Coach CSP CSM PSM I <chuck-lists2@...> wrote:

                                                    The only thing I might suggest adding is some small amount of clarification that poorly programmed code is not the same as code with defects, and thus code with defects requires a different approach.

                                                    Hm, in what way? 

                                                    Should the team randomly fix defects in code they're not working on as part of the Sprint? I don't think so. 

                                                    Should they fix them as part of cleaning the code they're working on? I would say yes.

                                                    When defects occur, I recommend scheduling the fixes just like any other story. And, of course, retrospecting to see what caused the issue and how to avoid it in the future.


                                                    And we have not addressed at all what a team should do "in their free time". 

                                                    Ron Jeffries
                                                    If another does not intend offense, it is wrong for me to seek it;
                                                    if another does indeed intend offense, it is foolish for me to permit it.
                                                      -- Kelly Easterley





                                                  • Michael Wollin
                                                    Perhaps a naïve question, but with respect to this conversation, how best would one classify the need to incorporate third-party upgrades? ... Re:
                                                    Message 25 of 30 , Aug 23, 2012
                                                    • 0 Attachment
                                                      Re: [scrumdevelopment] "Business Value" v. "Potentially Implementable Feature" Perhaps a naïve question, but with respect to this conversation, how best would one classify the need to incorporate third-party upgrades?
                                                      As a user, I want my blah to work with a newer version of (Exchange, MacOS, Oracle, Java, Hibernate, MQ , ...) so that our third party support contracts are viable and our system will keep working.

                                                      On 8/22/12 2:23 PM, "RonJeffries" <ronjeffries@...> wrote:

                                                      We do not, repeat DO NOT, put code improvement "stories" in the Product Backlog. The main reason for this is that we cannot state the value of the improvement in any terms that the Product Owner can understand, and therefore the Product Owner can never schedule the stories. P.S. We don't know the value either.

                                                    • Victor Hugo de Oliveira
                                                      David, I would like to point out that in your text it seems you understand that business value is restricting the delivery of features. In my view, features is
                                                      Message 26 of 30 , Aug 23, 2012
                                                      • 0 Attachment
                                                        David,

                                                           I would like to point out that in your text it seems you understand that business value is restricting the delivery of features.
                                                           In my view, features is actually a very strict subset of business value.
                                                           What I mean by that is in the definition of feature.
                                                           A feature should have a function, be usable. In that sense, we are already attributing value to it by calling a set of lines of code a feature.
                                                           In the context of a business, everything we call a feature has at least business value potential as it is used or someone imagined it would. When someone calls the item a feature they attributed value to it, otherwise they would call it only "a bunch of code". And this leads to the very vertical view of implementation. It must have business value indeed.

                                                           Now a different discussion could arise if, on the other hand, you proposed doing a PBI that generates intangible value somehow. 
                                                           Also, I see that in Customer Development cycles a cross functional team may very well be posed with PBIs that have nothing to do with programming, even if there are programmers in the team.

                                                           To me the big distinction in Scrum would be a preference for tangible value, and in the case of a software project, it would be "potentially shippable software". The bigger the perception of value, the more making it should be considered.
                                                           I don't see that much has changed when we talk about a focus on Business Value in Scrum.

                                                        Best Regards,
                                                        Victor


                                                        On Wed, Jul 25, 2012 at 10:58 AM, David A Barrett <dave.barrett@...> wrote:
                                                         

                                                        There's been a lot of discussion here lately about delivering "business value" each Sprint, and I'm wondering if somehow we've lost track of the underlying concepts of Scrum (at least in this respect), and are simply getting caught in the trap of nit-picking about rules and definitions.  Loosing sight of forest for the trees, if you like.

                                                        I don't recall that ten years ago, when I took the CSM course (taught back then by Ken himself), any mention of "business value" as a Sprint deliverable.  The phrase that sticks in my mind, and that I'm sure was used over and over again, was "potentially implementable feature".  I'd have to say that, even today, I see "potentially implementable feature" as a far better guideline than "business value".

                                                        First off, developers build features, not business value.  Business value comes from the implementation of the features, their integration into the business processes and a whole range of other considerations that, strictly speaking, are beyond control of the developers.  Expecting Scrum to somehow manage these other external factors is most probably going to be a failure, and extremely likely to lead to unnecessary complications inside of Scrum.

                                                        Secondly, talking about "business value" seems to focus everyone's attention delivering something that the business can take and use, with some tangible benefit, each and every Sprint.  I don't think that was ever the intention of Scrum.  The idea is to iteratively and incrementally deliver something that eventually will be of business value, but not with any rule that each Sprint needs to deliver some of that business value.

                                                        Personally, I think "potentially implementable feature" is a perfect definition of a deliverable.  A feature is...well...a feature.  Something that the user can perceive.  So this practically forces the idea that the development has to slice vertically through application.  A DAO to extract data from an obscure database is never going to count as a feature in a business process application, so you can't make it a Sprint deliverable by itself - it has to be part of something that is a feature.  User Stories are a great starting place to make sure that you features slice this way and mesh nicely with Scrum.

                                                        There are lots of examples of "features" that have virtually no business value in and of themselves, and require the completion of other features to be "valuable".   We need to remember that this process is about building software, and incorporating the things that you (and the users) learn about the software as it's built.  It's not about creating a steady stream of new business value each Sprint.  It's great if you can deliver business value earlier, for sure, but I don't think even that needs to be a "rule" in Scrum.



                                                        Dave Barrett


                                                        This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please delete it and advise me (by return e-mail or otherwise) immediately.

                                                        Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez le supprimer et m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.




                                                        --
                                                        Atenciosamente,
                                                        Victor Hugo de Oliveira
                                                        follow me: @v_oliv
                                                        Professional Scrum Trainer (Scrum.org)
                                                        Diretor de Engenharia (Concrete Solutions)


                                                      • RonJeffries
                                                        Michael, ... That sounds like a business purpose to me ... Ron Jeffries www.XProgramming.com Don t ignore your dreams; don t work too much; say what you think;
                                                        Message 27 of 30 , Aug 24, 2012
                                                        • 0 Attachment
                                                          Michael,

                                                          On Aug 23, 2012, at 6:23 PM, Michael Wollin <yahoo@...> wrote:

                                                          Perhaps a naïve question, but with respect to this conversation, how best would one classify the need to incorporate third-party upgrades? 
                                                          As a user, I want my blah to work with a newer version of (Exchange, MacOS, Oracle, Java, Hibernate, MQ , ...) so that our third party support contracts are viable and our system will keep working. 

                                                          That sounds like a business purpose to me ...
                                                          Don't ignore your dreams; don't work too much; say what you think; cultivate friendships; be happy. -- Paul Graham

                                                        • RonJeffries
                                                          Hi Cass, ... Go for it. Please be sure my name is on it and put a tip jar nearby. :) Ron Jeffries www.XProgramming.com If it is more than you need, it is
                                                          Message 28 of 30 , Aug 24, 2012
                                                          • 0 Attachment
                                                            Hi Cass,

                                                            On Aug 22, 2012, at 3:22 PM, Cass Dalton <cassdalton73@...> wrote:

                                                            If you don't mind, I think I'm going to put that post on a wall at work

                                                            Go for it. Please be sure my name is on it and put a tip jar nearby. :)

                                                            Ron Jeffries
                                                            If it is more than you need, it is waste. -- Andy Seidl

                                                          • Charles Bradley - Scrum Coach CSP CSM PSM
                                                            ... Great Idea. Would make an excellent poster with Ron s shiny face and contact info on it.  The Technical Debt Credo Ron, will you hire me as your new
                                                            Message 29 of 30 , Aug 24, 2012
                                                            • 0 Attachment
                                                              > I think I'm going to put that post on a wall at work

                                                              Great Idea.

                                                              Would make an excellent poster with Ron's shiny face and contact info on it.  "The Technical Debt Credo"

                                                              Ron, will you hire me as your new marketing guy?  I know you like to get the phat consulting rates. Maybe I can help.  ;-) 
                                                               
                                                              -------
                                                              Charles Bradley
                                                              http://www.ScrumCrazy.com




                                                              From: Cass Dalton <cassdalton73@...>
                                                              To: scrumdevelopment@yahoogroups.com
                                                              Sent: Wednesday, August 22, 2012 1:22 PM
                                                              Subject: Re: [scrumdevelopment] "Business Value" v. "Potentially Implementable Feature"



                                                              If you don't mind, I think I'm going to put that post on a wall at work
                                                              On Aug 22, 2012 2:24 PM, "RonJeffries" <ronjeffries@...> wrote:
                                                               
                                                              Charles,

                                                              On Aug 22, 2012, at 1:24 PM, Charles Bradley - Scrum Coach CSP CSM PSM I <chuck-lists2@...> wrote:

                                                              Do you have your views on technical debt in something that is published?  I would love to see that as I think it's a view that does not get enough attention in the industry.

                                                              Let me put them right here. If anyone doesn't find them quite obvious and clear, please inquire.

                                                              Never give code to the Product Owner that is not well programmed. This means clear code, well factored, supported by sufficient tests to be sure that it works.

                                                              If we are later going to look at this code and say that it sucks, it is not clear, well factored and supported by sufficient tests right now. 

                                                              If we do not know what clear, well factored code, supported by tests looks like, find out. We are cheating our team, our Product Owner, and ourselves.

                                                              When we do give code to the Product Owner that is not clear, well factored, and supported by tests, know that we have done a bad thing. There is some reason for that. This is a top priority for our next Retrospective. Figure out why we are doing bad work and fix it. Stop doing bad work.

                                                              P.S. There is no tradeoff against this kind of quality. We cannot go faster by skimping on clear well factored code supported by tests. It will bite us in the ass. You wouldn't be reading this answer if it wasn't already biting you in the ass. Stop writing bad code.

                                                              OK, despite our best efforts, we turn out to be incompetent. We now have code in the system that isn't clear, well factored, and supported by enough tests. Perhaps we just noticed. Perhaps we have learned some stuff that we wish we had known sooner. Perhaps we bent under pressure. Doesn't matter. We do a Retrospective and figure out what caused it, and remove the cause. But the existing code is still bad. What do we do?

                                                              We do not, repeat DO NOT, put code improvement "stories" in the Product Backlog. The main reason for this is that we cannot state the value of the improvement in any terms that the Product Owner can understand, and therefore the Product Owner can never schedule the stories. P.S. We don't know the value either.

                                                              If we do put code improvement stories in the backlog, we can't count the work against our Product Burndown or other progress measurements.  Why not? Because we have already been paid for this work when we did it badly last time. We don't pay the mechanic again when he re-fixes the far. We don't pay the programmer again when he fixes what he did poorly last time. Anyway, don't schedule this work as stories in the backlog anyway. It's just wrong. Stop it.

                                                              Then what do we do about this bad code? I'm glad you asked.

                                                              If our Product Owner's stories do not cause us to make changes to the bad code, we leave it alone. It is not hurting anyone, and it will not rot. It will just sit there. Cleaning it up will take time away from stories, and it will pay off, if it ever does, an unknown amount at an unknown time in the future. Bad investment. 

                                                              If stories cause us to work in the bad code, the bad code will slow us down. It will make us throw up, causing extra breaks in the rest room. We will be sad. Therefore, follow the "Boy Scount Rule", "Always leave the campground cleaner than you found it". Clean up the code in a reasonable fashion. Do not take ten days to rewrite it. We don't know how and anyway it's inefficient. Just leave it better than it was. Over time, all the code that is troubling us will get better. 

                                                              That is all:
                                                              • Don't do it. 
                                                              • When we do it, figure out why and stop. 
                                                              • When we do it, leave it alone if it's not in the way. 
                                                              • If it is in the way, clean up the parts we pass through.

                                                              You may be wondering "How do we get the time to keep it clean? How do we get the time to improve the campground?"

                                                              We have a story to do. That story includes a certain amount of experimenting to figure it out. It includes enough testing to leave the code properly tested. It includes the time to make the code clean and well factored, including any code we have to touch to do the story. 

                                                              That's how much time the story takes. So, that's how much time we take to do it. If we take less time, we have just stuck a screwdriver into one of our own bodily orifices. Stop doing that. You'll get a rash.


                                                              So. Any followup questions?

                                                              Ron Jeffries
                                                              If another does not intend offense, it is wrong for me to seek it;
                                                              if another does indeed intend offense, it is foolish for me to permit it.
                                                                -- Kelly Easterley





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