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

Re: [XP] Re: valuable and less risky/less costly stories first

Expand Messages
  • Ed Kraay
    Hi, I m new to the group, but have Mike Cohn s book handy so I d thought I d do some paraphrasing. He suggests to do use the value/risk quadrant to think about
    Message 1 of 11 , Mar 2 5:19 PM
    • 0 Attachment
      Hi,

      I'm new to the group, but have Mike Cohn's book handy so I'd thought
      I'd do some paraphrasing.

      He suggests to do use the value/risk quadrant to think about
      prioritizing themes based on risk.

      High Risk | High Risk
      Low Value | High Value
      -----------------------------------------------
      Low risk | Low Risk
      Low value | High Value


      He suggests to prioritize in the order below.

      Avoid | Do First
      |
      ------------------------------------------------
      Do Last | Do Second
      |

      Imagine an arrow going starting from the high risk/high value
      quadrant, through the low risk/ high value quadrant, ending at the low
      risk/low value quadrant. Risk here is a sort of tie breaker between
      stories of equally high value and varying amounts of risk.

      However, based on your original question, I think you were looking for
      a paper that favored doing the opposite. If I understood correctly,
      doing low risk/high value themes first to get some momentum behind the
      project. I'm not aware of any paper that suggests this.

      However, we did this during our current project, but it is too soon to
      tell whether this was good for the life of the project. Since we did
      not have a significant risk to any one piece, it might have been OK.
      It showed the customers we are smart and got some easy wins for the
      developers which seemed to encourage them to this (new to them) agile
      process.

      Best regards,

      Ed

      On 3/2/06, banshee858 <cnett858@...> wrote:
      > >
      > > Can someone point me to a paper (or write one) that could persuade
      > > an XP Customer to choose "cheap"/valuable/non-risky features as
      > > higher priority than "expensive"/valuable/risky features.
      > >
      > Mike Cohn's book, "Agile Estimating & Planning", talks about this
      > issue. I do not recall the exact words (I am not at my regualr
      > office), but I thought the diagram he used to illustrate the idea was
      > good.
      >
      > Carlton
      >
      >
      >
      >
      >
      >
      > To Post a message, send it to: extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
      >
      > ad-free courtesy of objectmentor.com
      > Yahoo! Groups Links
      >
      >
      >
      >
      >
      >
      >
    • Steven Gordon
      I haven t read the book yet, but this decision usually involves more variables than just value and a single-dimensional risk, as well as more choices than
      Message 2 of 11 , Mar 3 12:22 AM
      • 0 Attachment
        I haven't read the book yet, but this decision usually involves more
        variables than just value and a single-dimensional risk, as well as more
        choices than either do it or not do it.

        For example, as Ed suggests, a team that is new to agile needs some quick
        wins to gain confidence (both their own and that of the stakeholders) and to
        establish good working relationships. Tackling high risk stories in the
        first few iterations seems like an unnecessary gamble for new teams. Even
        for a veteran team, if the risk in a story is more due to uncertainty than
        technical issues, then it would often make sense to tackle that story a
        bit later when the uncertainties have hopefully become clearer.

        Also, many risks can often be reduced by choosing to break out a substory
        and implement it (as opposed to either deciding to implement the whole story
        or not). Implementing a well-chosen substory should shed light on
        the technical issues, and demoing it to customers (or prospects or proxies)
        should resolve many other risks, yet we risk losing less time if we discover
        technical roadblocks or get the feedback that the requirement was
        misunderstood.

        There are likely to be other dimensions of risk (such as 3rd party APIs),
        and other external variables (such as team skill sets) that impact the
        tradeoffs. It is instructive to consider simple two-variable tradeoffs, but
        in reality, we must consider many different variables.

        Steven Gordon


        On 3/2/06, Ed Kraay <ekraay@...> wrote:
        >
        > Hi,
        >
        > I'm new to the group, but have Mike Cohn's book handy so I'd thought
        > I'd do some paraphrasing.
        >
        > He suggests to do use the value/risk quadrant to think about
        > prioritizing themes based on risk.
        >
        > High Risk | High Risk
        > Low Value | High Value
        > -----------------------------------------------
        > Low risk | Low Risk
        > Low value | High Value
        >
        >
        > He suggests to prioritize in the order below.
        >
        > Avoid | Do First
        > |
        > ------------------------------------------------
        > Do Last | Do Second
        > |
        >
        > Imagine an arrow going starting from the high risk/high value
        > quadrant, through the low risk/ high value quadrant, ending at the low
        > risk/low value quadrant. Risk here is a sort of tie breaker between
        > stories of equally high value and varying amounts of risk.
        >
        > However, based on your original question, I think you were looking for
        > a paper that favored doing the opposite. If I understood correctly,
        > doing low risk/high value themes first to get some momentum behind the
        > project. I'm not aware of any paper that suggests this.
        >
        > However, we did this during our current project, but it is too soon to
        > tell whether this was good for the life of the project. Since we did
        > not have a significant risk to any one piece, it might have been OK.
        > It showed the customers we are smart and got some easy wins for the
        > developers which seemed to encourage them to this (new to them) agile
        > process.
        >
        > Best regards,
        >
        > Ed
        >


        [Non-text portions of this message have been removed]
      • Kevin Rutherford
        Hi, ... The AgileNorth group has discussed this topic a couple of times. My notes from the most productive of those meetings are online at
        Message 3 of 11 , Mar 3 12:59 AM
        • 0 Attachment
          Hi,

          > Can someone point me to a paper (or write one) that could persuade
          > > an XP Customer to choose "cheap"/valuable/non-risky features as
          > > higher priority than "expensive"/valuable/risky features.
          >

          The AgileNorth group has discussed this topic a couple of times. My notes
          from the most productive of those meetings are online at
          http://silkandspinach.net/blog/2005/02/stories_and_spi.html
          Cheers,
          Kevin
          --
          http://silkandspinach.net
          http://www.agilenorth.net


          [Non-text portions of this message have been removed]
        • kouretasgoat
          Hi, and welcome to the group. Your original post immediately made me think of a quadrant-thingy like the ones you provided. Mine was a little different: Risk
          Message 4 of 11 , Mar 3 7:35 AM
          • 0 Attachment
            Hi, and welcome to the group.
            Your original post immediately made me think of a quadrant-thingy like
            the ones you provided. Mine was a little different:
            Risk discardspike backlogiterate Value

            Terry Wray

            - That which the fool does in the end, the wise man does in
            thebeginning. -- R. C. Tench


            --- In extremeprogramming@yahoogroups.com, "Ed Kraay" <ekraay@...>
            wrote:
            >
            > Hi,
            >
            > I'm new to the group, but have Mike Cohn's book handy so I'd thought
            > I'd do some paraphrasing.
            >
            > He suggests to do use the value/risk quadrant to think about
            > prioritizing themes based on risk.
            >
            > High Risk | High Risk
            > Low Value | High Value
            > -----------------------------------------------
            > Low risk | Low Risk
            > Low value | High Value
            >
            >
            > He suggests to prioritize in the order below.
            >
            > Avoid | Do First
            > |
            > ------------------------------------------------
            > Do Last | Do Second
            > |
            >
            > Imagine an arrow going starting from the high risk/high value
            > quadrant, through the low risk/ high value quadrant, ending at the low
            > risk/low value quadrant. Risk here is a sort of tie breaker between
            > stories of equally high value and varying amounts of risk.
            >
            > However, based on your original question, I think you were looking for
            > a paper that favored doing the opposite. If I understood correctly,
            > doing low risk/high value themes first to get some momentum behind the
            > project. I'm not aware of any paper that suggests this.
            >
            > However, we did this during our current project, but it is too soon to
            > tell whether this was good for the life of the project. Since we did
            > not have a significant risk to any one piece, it might have been OK.
            > It showed the customers we are smart and got some easy wins for the
            > developers which seemed to encourage them to this (new to them) agile
            > process.
            >
            > Best regards,
            >
            > Ed
            >
            > On 3/2/06, banshee858 cnett858@... wrote:
            > > >
            > > > Can someone point me to a paper (or write one) that could persuade
            > > > an XP Customer to choose "cheap"/valuable/non-risky features as
            > > > higher priority than "expensive"/valuable/risky features.
            > > >
            > > Mike Cohn's book, "Agile Estimating & Planning", talks about this
            > > issue. I do not recall the exact words (I am not at my regualr
            > > office), but I thought the diagram he used to illustrate the idea
            was
            > > good.
            > >
            > > Carlton
            > >
            > >
            > >
            > >
            > >
            > >
            > > To Post a message, send it to: extremeprogramming@...
            > >
            > > To Unsubscribe, send a blank message to:
            extremeprogramming-unsubscribe@...
            > >
            > > ad-free courtesy of objectmentor.com
            > > Yahoo! Groups Links
            > >
            > >
            > >
            > >
            > >
            > >
            > >
            >




            [Non-text portions of this message have been removed]
          • Keith Ray
            If you can make money with low risk, why wouldn t you? Marketing. Marketing would rather put 4 major new features on the retail box and associated
            Message 5 of 11 , Mar 3 8:25 AM
            • 0 Attachment
              If you can make money with low risk, why wouldn't you? Marketing.

              Marketing would rather put "4 major new features" on the retail box
              and associated advertising rather than "40 usability improvements".

              Though perhaps the best deal for the USER would actually be "3 major
              new features and 10 usability improvements" or even "2 major new
              features and 20 usability improvements". But the best deal for the
              SELLER would be whatever seems easier to sell.

              However, the sum total of of a lot of "small" improvements is the real
              difference between an iPod and the various mp3 players that preceded
              it.

              Video was a major feature added to the fourth generation iPod, but it
              was not valuable enough / too risky for the first or second generation
              iPods.

              --

              C. Keith Ray
              <http://homepage.mac.com/keithray/blog/index.html>
              <http://homepage.mac.com/keithray/xpminifaq.html>
              <http://homepage.mac.com/keithray/resume2.html>
            • kouretasgoat
              I guess the html didn t come along as it appeared in the post preview. Here s a text-only version: R Discard | Spike I ---------------------- S
              Message 6 of 11 , Mar 3 11:11 AM
              • 0 Attachment
                I guess the html didn't come along as it appeared in the post preview.
                Here's a text-only version:

                R Discard | Spike
                I ----------------------
                S Backlog | Iterate
                K V A L U E

                or verbosely:

                High Risk, Low Value: Discard (or avoid, at least postpone)
                Low Risk, Low Value: Backlog
                High Risk, High Value: Spike (make a simplistic prototype to test
                feasability. probably sooner, rather than later)
                Low Risk, High Value: Iterate (wouldn't it be nice if every feature
                were in this quadrant...sigh)

                Ed Kraay wrote:
                > On 3/3/06, kouretasgoat <twray@...> wrote:
                >> Hi, and welcome to the group.
                >> Your original post immediately made me think of a quadrant-thingy like
                >> the ones you provided. Mine was a little different:
                >> Risk discardspike backlogiterate Value
                >>
                >> Terry Wray
                >
                > Hi Terry,
                >
                > Thanks for the welcome message! I am glad I found this group. It helps
                > hearing others hash out these issues as my learning on agile is self
                > taught or from books. I am but a young paduan learner!
                >
                > I wasn't sure from your post how the quadrant worked. How is it
                oriented?
                >
                > Thanks,
                >
                > Ed

                > --- In extremeprogramming@yahoogroups.com, "Ed Kraay" <ekraay@>
                > wrote:
                > >
                > > Hi,
                > >
                > > I'm new to the group, but have Mike Cohn's book handy so I'd thought
                > > I'd do some paraphrasing.
                > >
                > > He suggests to do use the value/risk quadrant to think about
                > > prioritizing themes based on risk.
                > >
                > > High Risk | High Risk
                > > Low Value | High Value
                > > -----------------------------------------------
                > > Low risk | Low Risk
                > > Low value | High Value
                > >
                > >
                > > He suggests to prioritize in the order below.
                > >
                > > Avoid | Do First
                > > |
                > > ------------------------------------------------
                > > Do Last | Do Second
                > > |
                > >
                > > Imagine an arrow going starting from the high risk/high value
                > > quadrant, through the low risk/ high value quadrant, ending at the low
                > > risk/low value quadrant. Risk here is a sort of tie breaker between
                > > stories of equally high value and varying amounts of risk.
                > >
                > > However, based on your original question, I think you were looking for
                > > a paper that favored doing the opposite. If I understood correctly,
                > > doing low risk/high value themes first to get some momentum behind the
                > > project. I'm not aware of any paper that suggests this.
                > >
                > > However, we did this during our current project, but it is too soon to
                > > tell whether this was good for the life of the project. Since we did
                > > not have a significant risk to any one piece, it might have been OK.
                > > It showed the customers we are smart and got some easy wins for the
                > > developers which seemed to encourage them to this (new to them) agile
                > > process.
                > >
                > > Best regards,
                > >
                > > Ed
                > >
                > > On 3/2/06, banshee858 cnett858@ wrote:
                > > > >
                > > > > Can someone point me to a paper (or write one) that could persuade
                > > > > an XP Customer to choose "cheap"/valuable/non-risky features as
                > > > > higher priority than "expensive"/valuable/risky features.
                > > > >
                > > > Mike Cohn's book, "Agile Estimating & Planning", talks about this
                > > > issue. I do not recall the exact words (I am not at my regualr
                > > > office), but I thought the diagram he used to illustrate the idea
                > was
                > > > good.
                > > >
                > > > Carlton
                > > >
                > > >
                > > >
                > > >
                > > >
                > > >
                > > > To Post a message, send it to: extremeprogramming@
                > > >
                > > > To Unsubscribe, send a blank message to:
                > extremeprogramming-unsubscribe@
                > > >
                > > > ad-free courtesy of objectmentor.com
                > > > Yahoo! Groups Links
                > > >
                > > >
                > > >
                > > >
                > > >
                > > >
                > > >
                > >
                >
                >
                >
                >
                > [Non-text portions of this message have been removed]
                >
              • Ed Kraay
                Hi, ... You raise a good point, Keith, what sells isn t always what is good for users. To borrow yet again from Agile Estimating and Planning book, I ve
                Message 7 of 11 , Mar 3 11:21 AM
                • 0 Attachment
                  Hi,

                  > Though perhaps the best deal for the USER would actually be "3 major
                  > new features and 10 usability improvements" or even "2 major new
                  > features and 20 usability improvements". But the best deal for the
                  > SELLER would be whatever seems easier to sell.

                  You raise a good point, Keith, what sells isn't always what is good
                  for users. To borrow yet again from "Agile Estimating and Planning"
                  book, I've found that the Kano model
                  <http://www.betterproductdesign.net/tools/definition/kano.htm> works
                  pretty well to convince marketing to give up some exciter features for
                  more threshold or linear features. Since customers satisfaction won't
                  decrease by eliminating them, they are usually content with adding
                  maybe one or two exciters rather than 3 or 4, in favor for more
                  threshold features.

                  What I am not sure of, is where does usability fall? Is it a 'more is
                  better' type of feature, an 'I expect it to be that way' feature.
                  Actually doing the research and submitting the surveys would probably
                  be required for the product in question to know for sure. I have to
                  admit, I have yet to get one of these surveys into the hands of
                  customers. I use the model more to talk about the class of features
                  customers are asking for, and to push back on marketing from
                  requesting too many risky exciters to a release.

                  Best,

                  Ed
                • Jim Standley
                  This probably depends a lot on how people define and feel about risk. One favorite working definition (probably came from this discussion group) is
                  Message 8 of 11 , Mar 5 12:21 PM
                  • 0 Attachment
                    This probably depends a lot on how people define and feel about "risk."
                    One favorite working definition (probably came from this discussion
                    group) is "uncertainty in the plan." Given a bunch of things of equal
                    value, I'd be more comfortable investing some work in eliminating the
                    dark corners where I can't quite see how it's going to work out yet.

                    I kind of like the "warm up" idea, too. We did a platform change a
                    couple years back so everything was new and we did a few easy things
                    first with a subset of the coders to get a feel for how it all hung
                    together and put up some procedures. Can you keep it small and focused
                    on warming up, recognizing it might not be the highest value?

                    Keith Ray wrote:
                    > Can someone point me to a paper (or write one) that could persuade an
                    > XP Customer to choose "cheap"/valuable/non-risky features as higher
                    > priority than "expensive"/valuable/risky features.
                    >
                    > Others have advocated putting "risky" stuff first [this tends to come
                    > up in scrum writings a lot], but I think valuable non-risky items
                    > should be done first to "warm up" the team to the process/project.
                    >
                    > And of course, if someone is risky but not valuable, then it should be
                    > low priority... however too much focus on risk tends to prioritize
                    > those features too high as well.
                    >
                    > --
                    >
                    > C. Keith Ray
                    > <http://homepage.mac.com/keithray/blog/index.html>
                    > <http://homepage.mac.com/keithray/xpminifaq.html>
                    > <http://homepage.mac.com/keithray/resume2.html>
                    >
                    >
                    > To Post a message, send it to: extremeprogramming@...
                    >
                    > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                    >
                    > ad-free courtesy of objectmentor.com
                    > Yahoo! Groups Links
                    >
                    >
                    >
                    >
                    >
                    >
                    >
                  • Greg Akins
                    Something I didn t think of, while reading the earlier posts; and I think it get s at the crux of what Keith originally asked about. How many project put a
                    Message 9 of 11 , Mar 6 5:47 AM
                    • 0 Attachment
                      Something I didn't think of, while reading the earlier posts; and I
                      think it get's at the crux of what Keith originally asked about.

                      How many project put a risk factor on not even being able to implement
                      a simple system without thrashing?

                      I'm working on a app now where the lead/architect continually puts
                      automated testing and an automated build process at the bottom of a
                      list of priorities because "we need to deliver features, or the
                      project will be cancelled"

                      If we had put a low risk story in place with a full CI system, we'd
                      have saved a lot of thrashing later in the project. And significantly
                      reduced the probability of bad things happening on more complicated /
                      risky stories later in development.

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