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

Buyin

Expand Messages
  • Freya Watts
    Does anyone have any sure fire tips for getting customers (internal or external) on board with moving from traditional development methods to Scrum? I am
    Message 1 of 12 , Nov 1, 2004

      Does anyone have any sure fire tips for getting “customers” (internal or external) on board with moving from traditional development methods to Scrum? I am finding that it’s much more difficult if there are a number of people whose requirements are being moved to the product backlog and I am constantly met with the question “When are my requirements going to be delivered? I need a date”. As I am not putting together a long-term project plan with Scrum but really only planning one or two Sprints in advance, I don’t have a ready answer apart from the fact that the future sprint dates are known and the priorities will roughly (emphasis on the roughly) match up to this i.e. priority 1 will be dealt with in the next sprint, priority 2 in the one after that. This feeling tends to be less prevalent in projects where Scrum is used from the start but as this is a fairly new concept I am trying out at the moment, most of our projects are “converts” from traditional methods. Are there any types of projects that are easier to convert than others?

       

      I would also appreciate any analogies that could be used to help gain customers buy-in and focus their minds on thinking at a higher level with regards requirements. Putting together a sprint objective seems to be particularly hard for them.

       

      Sorry for all the questions at once

       

      Cheers

       

      Geoff

    • Steven Gordon
      Geoff, It sounds like it is you who are determining the requirements for each sprint. You might consider letting your customers vote on which requirements each
      Message 2 of 12 , Nov 1, 2004
        Geoff,

        It sounds like it is you who are determining the requirements for each
        sprint.

        You might consider letting your customers vote on which requirements
        each sprint will try to fulfill (the requirements in a sprint do not have to
        add up to a single coherent requirement). Every customer could have
        the same number of votes, or the votes could be proportional to how
        much each customer is paying for development or how long since their
        last requirement was fulfilled or poltical clout or whatever.

        By having the customer's officially determine when each requirement is
        implemented, then they provide their own answer as to when. It also
        facilitates steering the project to respond to changing urgencies, which
        should please any customer.

        Steven Gordon
        http://sf.asu.edu/

        -----Original Message-----
        From: Freya Watts [mailto:freyawatts@...]
        Sent: Mon 11/1/2004 7:23 AM
        To: scrumdevelopment@yahoogroups.com
        Cc:
        Subject: [scrumdevelopment] Buyin


        Does anyone have any sure fire tips for getting “customers” (internal or external) on board with moving from traditional development methods to Scrum? I am finding that it’s much more difficult if there are a number of people whose requirements are being moved to the product backlog and I am constantly met with the question “When are my requirements going to be delivered? I need a date”. As I am not putting together a long-term project plan with Scrum but really only planning one or two Sprints in advance, I don’t have a ready answer apart from the fact that the future sprint dates are known and the priorities will roughly (emphasis on the roughly) match up to this i.e. priority 1 will be dealt with in the next sprint, priority 2 in the one after that. This feeling tends to be less prevalent in projects where Scrum is used from the start but as this is a fairly new concept I am trying out at the moment, most of our projects are “converts” from traditional methods. Are there any types of projects that are easier to convert than others?

        I would also appreciate any analogies that could be used to help gain customers buy-in and focus their minds on thinking at a higher level with regards requirements. Putting together a sprint objective seems to be particularly hard for them.

        Sorry for all the questions at once

        Cheers

        Geoff
      • David Moskowitz
        Maybe I ve missed something... Can we assume that they (the customers and the organization) have bough in to the idea of agile (any agile process)? From
        Message 3 of 12 , Nov 1, 2004
          Maybe I've missed something...

          Can we assume that they (the customers and the organization) have
          bough in to the idea of "agile" (any agile process)? From the
          questions you've asked I wasn't sure.

          You asked for "sure fire" -- Do they understand the benefits of what
          an agile approach using Scrum? If not, I'd start there.

          Then you have to make sure that everyone fully participates... but
          that might be a separate question/issue.

          David


          On Mon, 1 Nov 2004 14:23:18 -0000, Freya Watts
          <freyawatts@...> wrote:
          >
          > Does anyone have any sure fire tips for getting "customers" (internal or
          > external) on board with moving from traditional development methods to
          > Scrum? I am finding that it's much more difficult if there are a number of
          > people whose requirements are being moved to the product backlog and I am
          > constantly met with the question "When are my requirements going to be
          > delivered? I need a date". As I am not putting together a long-term project
          > plan with Scrum but really only planning one or two Sprints in advance, I
          > don't have a ready answer apart from the fact that the future sprint dates
          > are known and the priorities will roughly (emphasis on the roughly) match up
          > to this i.e. priority 1 will be dealt with in the next sprint, priority 2 in
          > the one after that. This feeling tends to be less prevalent in projects
          > where Scrum is used from the start but as this is a fairly new concept I am
          > trying out at the moment, most of our projects are "converts" from
          > traditional methods. Are there any types of projects that are easier to
          > convert than others?
          >
          > I would also appreciate any analogies that could be used to help gain
          > customers buy-in and focus their minds on thinking at a higher level with
          > regards requirements. Putting together a sprint objective seems to be
          > particularly hard for them.
          ...snip...
        • Freya Watts
          Thanks Steve Thanks for your comments and I like the idea of voting although somewhere along the line there is always an arbitrary decision - be it who gets
          Message 4 of 12 , Nov 1, 2004
            Thanks Steve

            Thanks for your comments and I like the idea of voting although somewhere
            along the line there is always an arbitrary decision - be it who gets what
            votes or who is the person responsible overall. At the moment we are
            attempting to get someone to fill the role of product owner who prioritises
            anything that comes on the product backlog. I don't want the scrum
            team/scrum master to be deciding prioritisations as that really doesn't
            offer a lot to the people sponsoring or receiving the system. However, once
            prioritised (preferably by someone on the customer side), the scrum team are
            then taking requirements in a prioritised manner on to the spring backlog.

            My issue is mainly because it's a new process that I am trying to get
            business-wide support for, I am attempting to gain buy-in from everyone.
            People whose requirements are top of the list love the increased focus and
            progress on their work. However, I'm finding it difficult to placate people
            who are used to project plans that, although being extremely vague and
            unlikely to be anywhere near accurate, give people a date they can cling to.
            If their requirements aren't in one of the next 2 sprints, they don't have a
            date to pin their hopes to. Seems silly I guess but I'm still a rookie here
            trying to learn from others successes/mistakes.

            Your help is appreciated

            Geoff

            _____

            From: Steven Gordon [mailto:sagordon@...]
            Sent: 01 November 2004 14:43
            To: scrumdevelopment@yahoogroups.com
            Subject: RE: [scrumdevelopment] Buyin

            Geoff,

            It sounds like it is you who are determining the requirements for each
            sprint.

            You might consider letting your customers vote on which requirements
            each sprint will try to fulfill (the requirements in a sprint do not have to

            add up to a single coherent requirement). Every customer could have
            the same number of votes, or the votes could be proportional to how
            much each customer is paying for development or how long since their
            last requirement was fulfilled or poltical clout or whatever.

            By having the customer's officially determine when each requirement is
            implemented, then they provide their own answer as to when. It also
            facilitates steering the project to respond to changing urgencies, which
            should please any customer.

            Steven Gordon
            http://sf.asu.edu/

            -----Original Message-----
            From: Freya Watts [mailto:freyawatts@...]
            Sent: Mon 11/1/2004 7:23 AM
            To: scrumdevelopment@yahoogroups.com
            Cc:
            Subject: [scrumdevelopment] Buyin
            Does anyone have any sure fire tips for getting "customers" (internal or
            external) on board with moving from traditional development methods to
            Scrum? I am finding that it's much more difficult if there are a number of
            people whose requirements are being moved to the product backlog and I am
            constantly met with the question "When are my requirements going to be
            delivered? I need a date". As I am not putting together a long-term project
            plan with Scrum but really only planning one or two Sprints in advance, I
            don't have a ready answer apart from the fact that the future sprint dates
            are known and the priorities will roughly (emphasis on the roughly) match up
            to this i.e. priority 1 will be dealt with in the next sprint, priority 2 in
            the one after that. This feeling tends to be less prevalent in projects
            where Scrum is used from the start but as this is a fairly new concept I am
            trying out at the moment, most of our projects are "converts" from
            traditional methods. Are there any types of projects that are easier to
            convert than others?

            I would also appreciate any analogies that could be used to help gain
            customers buy-in and focus their minds on thinking at a higher level with
            regards requirements. Putting together a sprint objective seems to be
            particularly hard for them.

            Sorry for all the questions at once

            Cheers

            Geoff
          • Ron Jeffries
            ... Freya, some thoughts: First of all, what you re doing now isn t meeting these people s needs or wants. They want a date, and you re not giving it to them.
            Message 5 of 12 , Nov 1, 2004
              On Monday, November 1, 2004, at 9:23:18 AM, Freya Watts wrote:

              > Does anyone have any sure fire tips for getting "customers" (internal or
              > external) on board with moving from traditional development methods to
              > Scrum? I am finding that it's much more difficult if there are a number of
              > people whose requirements are being moved to the product backlog and I am
              > constantly met with the question "When are my requirements going to be
              > delivered? I need a date".

              Freya, some thoughts:

              First of all, what you're doing now isn't meeting these people's needs or
              wants. They want a date, and you're not giving it to them. It's perhaps
              unlikely that you'll succeed in making them happy without fulfilling that
              desire.

              Second, it's at least possible to do a longer-range plan, and even to
              budget X amount of time, starting N sprints from now, for these people's
              stuff.

              Third, I'm wondering how these questions were answered before you went to
              Scrum, and what's stopping you from doing at least that good [bad?] a job
              now?

              Regards,

              Ron Jeffries
              www.XProgramming.com
              You don't need to see my identification.
              These aren't the ideas you're looking for. Move along.
            • Ron Jeffries
              ... Hi Geoff. I called you Freya earlier, because, as you probably know, that s what your email address suggests. Sorry for the confusion. Ron Jeffries
              Message 6 of 12 , Nov 1, 2004
                On Monday, November 1, 2004, at 11:09:08 AM, Freya Watts [or not] wrote:

                > Thanks Steve

                Hi Geoff. I called you Freya earlier, because, as you probably know, that's
                what your email address suggests. Sorry for the confusion.

                Ron Jeffries
                www.XProgramming.com
                To be on the wire is life. The rest is waiting. --Karl Wallenda
              • Brad Appleton
                ... You might take a look at some of the buy-in/consensus strategies in an article entitled Agile Change Management: from First Principles to Best-Practices
                Message 7 of 12 , Nov 1, 2004
                  On Mon, Nov 01, 2004 at 10:09:08AM -0600, Freya Watts wrote:
                  > Thanks Steve
                  >
                  > Thanks for your comments and I like the idea of voting although somewhere along the line there is always an arbitrary decision - be it who gets what votes or who is the person responsible overall. At the moment we are attempting to get someone to fill the role of product owner who prioritizes
                  > anything that comes on the product backlog. I don't want the scrum team/scrum master to be deciding prioritisations as that really doesn't offer a lot to the people sponsoring or receiving the system. However, once prioritised (preferably by someone on the customer side), the scrum team are then
                  > taking requirements in a prioritised manner on to the spring backlog.

                  You might take a look at some of the buy-in/consensus
                  strategies in an article entitled "Agile Change Management:
                  from First Principles to Best-Practices" at
                  <http://www.cmcrossroads.com/articles/agileaug03.html>

                  It talks about the role of the "product champion" in
                  getting "one voice" from the customer regarding priorities,
                  and several participatory decision-making strategies for
                  doing just that.

                  You might also look at QFD (Quality-Function Deployment)
                  as it has some strategies for that sort of thing as well,
                  if you can intuit how to make them lean/agile from the
                  way that QFD is often practiced.

                  --
                  Brad Appleton <brad@...> www.bradapp.net
                  Software CM Patterns (www.scmpatterns.com)
                  Effective Teamwork, Practical Integration
                  "And miles to go before I sleep." -- Robert Frost
                • Freya Watts
                  I seem to be making progress in convincing customers about the agile process and certainly developers. As this isn t being driven by the business, it s just
                  Message 8 of 12 , Nov 1, 2004

                    I seem to be making progress in convincing customers about the agile process and certainly developers. As this isn’t being driven by the business, it’s just something I believe in and have got some backing to trial, I am trying to win people over as I go and then provide some evidence to the decision-makers on policy/process that this is a winner.

                     

                    I’m guessing you have all come across these sorts of issues before and am trying to draw on your experience on how to get the buy-in of people who don’t have to change. It would be a lot easier if it was a business-wide initiative (or even a unit-wide initiative) but until I can prove the theory I was looking for some tips. Sorry if I haven’t explained myself very well

                     

                    Cheers

                     

                    Geoff/Freya

                     


                    From: David Moskowitz [mailto:david.moskowitz@...]
                    Sent: 01 November 2004 15:25
                    To: scrumdevelopment@yahoogroups.com
                    Subject: Re: [scrumdevelopment] Buyin

                     

                    Maybe I've missed something... 

                    Can we assume that they (the customers and the organization) have
                    bough in to the idea of "agile" (any agile process)?    From the
                    questions you've asked I wasn't sure.

                    You asked for "sure fire" -- Do they understand the benefits of what
                    an agile approach using Scrum?  If not, I'd start there.

                    Then you have to make sure that everyone fully participates...  but
                    that might be a separate question/issue.

                    David


                    On Mon, 1 Nov 2004 14:23:18 -0000, Freya Watts
                    <freyawatts@...> wrote:

                    > Does anyone have any sure fire tips for getting "customers" (internal or
                    > external) on board with moving from traditional development methods to
                    > Scrum? I am finding that it's much more difficult if there are a number of
                    > people whose requirements are being moved to the product backlog and I am
                    > constantly met with the question "When are my requirements going to be
                    > delivered? I need a date". As I am not putting together a long-term project
                    > plan with Scrum but really only planning one or two Sprints in advance, I
                    > don't have a ready answer apart from the fact that the future sprint dates
                    > are known and the priorities will roughly (emphasis on the roughly) match up
                    > to this i.e. priority 1 will be dealt with in the next sprint, priority 2 in
                    > the one after that. This feeling tends to be less prevalent in projects
                    > where Scrum is used from the start but as this is a fairly new concept I am
                    > trying out at the moment, most of our projects are "converts" from
                    > traditional methods. Are there any types of projects that are easier to
                    > convert than others?
                    >
                    > I would also appreciate any analogies that could be used to help gain
                    > customers buy-in and focus their minds on thinking at a higher level with
                    > regards requirements. Putting together a sprint objective seems to be
                    > particularly hard for them.
                    ...snip...


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




                  • Ron Jeffries
                    ... What is it that you want the people you re convincing to do? What will be better about agile processes, for you, and for them? Ron Jeffries
                    Message 9 of 12 , Nov 1, 2004
                      On Monday, November 1, 2004, at 3:34:53 PM, Freya Watts wrote:

                      > I seem to be making progress in convincing customers about the agile process
                      > and certainly developers. As this isn't being driven by the business, it's
                      > just something I believe in and have got some backing to trial, I am trying
                      > to win people over as I go and then provide some evidence to the
                      > decision-makers on policy/process that this is a winner.

                      > I'm guessing you have all come across these sorts of issues before and am
                      > trying to draw on your experience on how to get the buy-in of people who
                      > don't have to change. It would be a lot easier if it was a business-wide
                      > initiative (or even a unit-wide initiative) but until I can prove the theory
                      > I was looking for some tips. Sorry if I haven't explained myself very well

                      What is it that you want the people you're convincing to do? What will be
                      better about agile processes, for you, and for them?

                      Ron Jeffries
                      www.XProgramming.com
                      If not now, when? -- The Talmud
                    • Gary F
                      ... We did a sort of QFD-light when I was at DEC. (It was commonly called QFD internally, but consultants who had worked on QFD in Japan thought we had barely
                      Message 10 of 12 , Nov 1, 2004
                        --- Brad Appleton <brad@...> wrote:

                        > You might also look at QFD (Quality-Function Deployment)
                        > as it has some strategies for that sort of thing as well,
                        > if you can intuit how to make them lean/agile from the
                        > way that QFD is often practiced.

                        We did a sort of QFD-light when I was at DEC. (It was commonly called
                        QFD internally, but consultants who had worked on QFD in Japan thought
                        we had barely scratched the surface.) In any event, it was essentially
                        a way to derive priorities by mapping customer values against features.
                        Typical sessions were one to three days depending upon the number of
                        participants; they tended to be very intense.

                        I'm not sure what you have in mind by "the way that QFD is often
                        practiced", but for us it was strong customer collaboration and an
                        opportunity for intense face-to-face communication, both very important
                        points.

                        The downside is the tendancy, after that much work, to treat the
                        results of the QFD as carved in stone. I don't believe there's
                        anything specific to the way we did QFD that required that; indeed, if
                        the data was online, and the customers' priorities changed among the
                        existing value sets, one could easily plug in the changes and reorder
                        the priorities.

                        Also, both customer and developers might fall into the trap of saying
                        "ok, we have the priorities, we don't need to talk to each other for
                        another year," but that, too, can be avoided if you're aware of the
                        problem. The QFD sessions had the side effect of being a great
                        team-building exercise between the customers and developers, so in that
                        sense, it can be considered an enabler of frequent customer
                        collaboration.

                        Gary



                        __________________________________
                        Do you Yahoo!?
                        Check out the new Yahoo! Front Page.
                        www.yahoo.com
                      • Schiel James - SHS Malvern
                        One thought -- Many of your customers seem like they re still thinking in the traditional project planning mode (i.e., plan the whole schedule up front).
                        Message 11 of 12 , Nov 1, 2004
                          One thought --
                           
                          Many of your customers seem like they're still thinking in the traditional project planning mode (i.e., plan the whole schedule up front). Perhaps you should consider creating a project-construct that will be built from some number of sprints with a planned delivery date at the end. Then, you can tell the customers you are able to scope into those sprints that their planned delivery date is your planned delivery date. Sprint works fine in this scenario -- but you'll still need to get the requirements/features prioritized and tenatively planned for the sprints within your project construct.  Make sense?
                           
                          Jim
                          -----Original Message-----
                          From: Freya Watts [mailto:freyawatts@...]
                          Sent: Monday, November 01, 2004 3:35 PM
                          To: scrumdevelopment@yahoogroups.com
                          Subject: RE: [scrumdevelopment] Buyin

                          I seem to be making progress in convincing customers about the agile process and certainly developers. As this isn’t being driven by the business, it’s just something I believe in and have got some backing to trial, I am trying to win people over as I go and then provide some evidence to the decision-makers on policy/process that this is a winner.

                           

                          I’m guessing you have all come across these sorts of issues before and am trying to draw on your experience on how to get the buy-in of people who don’t have to change. It would be a lot easier if it was a business-wide initiative (or even a unit-wide initiative) but until I can prove the theory I was looking for some tips. Sorry if I haven’t explained myself very well

                           

                          Cheers

                           

                          Geoff/Freya

                           


                          From: David Moskowitz [mailto:david.moskowitz@...]
                          Sent: 01 November 2004 15:25
                          To: scrumdevelopment@yahoogroups.com
                          Subject: Re: [scrumdevelopment] Buyin

                           

                          Maybe I've missed something... 

                          Can we assume that they (the customers and the organization) have
                          bough in to the idea of "agile" (any agile process)?    From the
                          questions you've asked I wasn't sure.

                          You asked for "sure fire" -- Do they understand the benefits of what
                          an agile approach using Scrum?  If not, I'd start there.

                          Then you have to make sure that everyone fully participates...  but
                          that might be a separate question/issue.

                          David


                          On Mon, 1 Nov 2004 14:23:18 -0000, Freya Watts
                          <freyawatts@...> wrote:

                          > Does anyone have any sure fire tips for getting "customers" (internal or
                          > external) on board with moving from traditional development methods to
                          > Scrum? I am finding that it's much more difficult if there are a number of
                          > people whose requirements are being moved to the product backlog and I am
                          > constantly met with the question "When are my requirements going to be
                          > delivered? I need a date". As I am not putting together a long-term project
                          > plan with Scrum but really only planning one or two Sprints in advance, I
                          > don't have a ready answer apart from the fact that the future sprint dates
                          > are known and the priorities will roughly (emphasis on the roughly) match up
                          > to this i.e. priority 1 will be dealt with in the next sprint, priority 2 in
                          > the one after that. This feeling tends to be less prevalent in projects
                          > where Scrum is used from the start but as this is a fairly new concept I am
                          > trying out at the moment, most of our projects are "converts" from
                          > traditional methods. Are there any types of projects that are easier to
                          > convert than others?
                          >
                          > I would also appreciate any analogies that could be used to help gain
                          > customers buy-in and focus their minds on thinking at a higher level with
                          > regards requirements. Putting together a sprint objective seems to be
                          > particularly hard for them.
                          ...snip...


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






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



                          -------------------------------------------------------------------------------
                          This message and any included attachments are from Siemens Medical Solutions
                          USA, Inc. and are intended only for the addressee(s).
                          The information contained herein may include trade secrets or privileged or
                          otherwise confidential information. Unauthorized review, forwarding, printing,
                          copying, distributing, or using such information is strictly prohibited and may
                          be unlawful. If you received this message in error, or have reason to believe
                          you are not authorized to receive it, please promptly delete this message and
                          notify the sender by e-mail with a copy to Central.SecurityOffice@...

                          Thank you
                        • Freya Watts
                          Thanks - it s one step at a time at the moment. Changing the mindset of others, like you say, is the key and I can only do that gradually so it will probably
                          Message 12 of 12 , Nov 3, 2004

                            Thanks – it’s one step at a time at the moment. Changing the mindset of others, like you say, is the key and I can only do that gradually so it will probably be an ugly transition phase from traditional to agile for a while making compromises on the way.

                             

                            Thanks to all for their comments.

                             


                            From: Schiel James - SHS Malvern [mailto:james.schiel@...]
                            Sent: 02 November 2004 02:15
                            To: ' scrumdevelopment@yahoogroups.com '
                            Subject: RE: [scrumdevelopment] Buyin

                             

                            One thought --

                             

                            Many of your customers seem like they're still thinking in the traditional project planning mode (i.e., plan the whole schedule up front). Perhaps you should consider creating a project-construct that will be built from some number of sprints with a planned delivery date at the end. Then, you can tell the customers you are able to scope into those sprints that their planned delivery date is your planned delivery date. Sprint works fine in this scenario -- but you'll still need to get the requirements/features prioritized and tenatively planned for the sprints within your project construct.  Make sense?

                             

                            Jim

                            -----Original Message-----
                            From: Freya Watts [mailto:freyawatts@...]
                            Sent: Monday, November 01, 2004 3:35 PM
                            To: scrumdevelopment@yahoogroups.com
                            Subject: RE: [scrumdevelopment] Buyin

                            I seem to be making progress in convincing customers about the agile process and certainly developers. As this isn’t being driven by the business, it’s just something I believe in and have got some backing to trial, I am trying to win people over as I go and then provide some evidence to the decision-makers on policy/process that this is a winner.

                             

                            I’m guessing you have all come across these sorts of issues before and am trying to draw on your experience on how to get the buy-in of people who don’t have to change. It would be a lot easier if it was a business-wide initiative (or even a unit-wide initiative) but until I can prove the theory I was looking for some tips. Sorry if I haven’t explained myself very well

                             

                            Cheers

                             

                            Geoff/Freya

                             


                            From: David Moskowitz [mailto:david.moskowitz@...]
                            Sent: 01 November 2004 15:25
                            To: scrumdevelopment@yahoogroups.com
                            Subject: Re: [scrumdevelopment] Buyin

                             

                            Maybe I've missed something... 

                            Can we assume that they (the customers and the organization) have
                            bough in to the idea of "agile" (any agile process)?    From the
                            questions you've asked I wasn't sure.

                            You asked for "sure fire" -- Do they understand the benefits of what
                            an agile approach using Scrum?  If not, I'd start there.

                            Then you have to make sure that everyone fully participates...  but
                            that might be a separate question/issue.

                            David


                            On Mon, 1 Nov 2004 14:23:18 -0000, Freya Watts
                            <freyawatts@...> wrote:

                            > Does anyone have any sure fire tips for getting "customers" (internal or
                            > external) on board with moving from traditional development methods to
                            > Scrum? I am finding that it's much more difficult if there are a number of
                            > people whose requirements are being moved to the product backlog and I am
                            > constantly met with the question "When are my requirements going to be
                            > delivered? I need a date". As I am not putting together a long-term project
                            > plan with Scrum but really only planning one or two Sprints in advance, I
                            > don't have a ready answer apart from the fact that the future sprint dates
                            > are known and the priorities will roughly (emphasis on the roughly) match up
                            > to this i.e. priority 1 will be dealt with in the next sprint, priority 2 in
                            > the one after that. This feeling tends to be less prevalent in projects
                            > where Scrum is used from the start but as this is a fairly new concept I am
                            > trying out at the moment, most of our projects are "converts" from
                            > traditional methods. Are there any types of projects that are easier to
                            > convert than others?
                            >
                            > I would also appreciate any analogies that could be used to help gain
                            > customers buy-in and focus their minds on thinking at a higher level with
                            > regards requirements. Putting together a sprint objective seems to be
                            > particularly hard for them.
                            ...snip...


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






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




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




                            -------------------------------------------------------------------------------
                            This message and any included attachments are from Siemens Medical Solutions
                            USA, Inc. and are intended only for the addressee(s).
                            The information contained herein may include trade secrets or privileged or
                            otherwise confidential information. Unauthorized review, forwarding, printing,
                            copying, distributing, or using such information is strictly prohibited and may
                            be unlawful. If you received this message in error, or have reason to believe
                            you are not authorized to receive it, please promptly delete this message and
                            notify the sender by e-mail with a copy to Central.SecurityOffice@...

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