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

RE: [scrumdevelopment] SCRUM process with other methodologies

Expand Messages
  • Reginald Braithwaite-Lee
    ... Whenever possible, I like to use corkboards or whiteboards. I m considering using a projector and a dedicated PC on my next project for things that don t
    Message 1 of 22 , Apr 6, 2004
      --- Mike Cohn <mike@...> wrote:
      > I have successfully used:
      >
      > --cards
      > --a wiki
      > --rows in Excel
      > --TestTrack (a defect tracker, with each story/task entered as a
      > record)

      Whenever possible, I like to use corkboards or whiteboards. I'm
      considering using a projector and a dedicated PC on my next project for
      things that don't work well on paper.

      http://www.braithwaite-lee.com/opinions/cork-board.html

      --
      Reginald Braithwaite-Lee
      http://www.braithwaite-lee.com

      "Even when my proposals are seen as significant improvements, they are
      often rejected on the grounds that they are not intuitive. It is a
      classic Catch-22: The client wants something that is significantly
      superior to the competition. But if it is to be superior, it must be
      different. (Typically, the greater the improvement, the greater the
      difference.) Therefore, it cannot be intuitive, that is, familiar. What
      the client wants is an interface with at most marginal differences from
      current practice... that, somehow, makes a major improvement." --Jef
      Raskin


      __________________________________
      Do you Yahoo!?
      Yahoo! Small Business $15K Web Design Giveaway
      http://promotions.yahoo.com/design_giveaway/
    • Roberts, David J (CNSP N6124V13)
      I would say so. That s why we do empirical. David Roberts TRMS Technical Lead (619) 368-9621 ... From: Ron Jeffries [mailto:ronjeffries@XProgramming.com] Sent:
      Message 2 of 22 , Apr 6, 2004

        I would say so. That's why we do empirical.

         

        David Roberts

        TRMS Technical Lead

        (619) 368-9621

         

        -----Original Message-----
        From: Ron Jeffries [mailto:ronjeffries@...]
        Sent: Monday, April 05, 2004 7:23 PM
        To: scrumdevelopment@yahoogroups.com
        Subject: Re: [scrumdevelopment] SCRUM process with other methodologies

         

        On Monday, April 5, 2004, at 9:23:18 PM, Roberts, David J (CNSP N6124V13) wrote:

        > I find the time features are found to be necessary always seems to come
        > after you've developed something. You're lucky if otherwise is true for you.

        > I see developers having these meeting with customers. The developers leave
        > thinking, "I've locked down these requirements!" and the customer leaves
        > thinking "I know what they're going to build me". Both are problematic.

        Isn't that why Scrum ships software every month, and XP and Crystal even
        more often?

        Ron Jeffries
        www.XProgramming.com
        Anyone can make the simple complicated.
        Creativity is making the complicated simple. -- Charles Mingus



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



      • Claude Montpetit
        We just implemented a Scrum process and there are many stories that were added just for requirement analysis. This became necessary because the product is
        Message 3 of 22 , Apr 6, 2004
          We just implemented a Scrum process and there are many stories that
          were added just for requirement analysis. This became necessary
          because the product is already sold and installed at some customer
          locations (a server product). These customers have custom
          requirements that we do for them and they (generally) pay us. So we
          need to estimate the work required for it. Producing an estimate is
          therefore a story that must be prioritized. Once the estimate is
          completed and the quote sent to the customer, another story is created
          in the product backlog:

          Implement request X for customer Y based on estimate Z

          Implementing Scrum is very new to me and I am not sure about how to
          deal with, for example, urgent estimates that must enter the current
          sprint. Telling the salesman to wait for the next iteration for the
          quote is not usually a good thing as it means that the implementation
          would in theory start very late:

          - month 1: submit the request
          - month 2: produce the estimate
          - month 3: implement the request

          This is not practical of course so we have been inserting estimates in
          the current sprint and informed the customer that he must decide in
          the current month whether he wants to go ahead or not if he wants it
          to be done in the next sprint.

          One of the strongest problem I had (and still have) implementing this
          process was to convince people outside of the development team
          (client, marketing, sales) that they should know about details of the
          products (bugs, certain improvements that look "too technical"...)

          Once the product backlog was transfered to "clients", and when I asked
          them to prioritize items, they thought that there was too many
          details. I then realized that they felt this way because they did not
          understand the product enough, and that the development team had been
          driving the product on their own since day one. Changing this around
          is a real challenge. For this reason, I am currently acting as both
          the Scrum master and the product owner until I can find someone
          outside the dev team that will take the product owner role and manage
          priorities.

          But overall, the implementation of a well defined process (Scrum) has
          been welcomed by the client/marketing/sales side as they know what we
          are working on now and they have control on what is next.

          -
          Claude Montpetit
          http://www.montpetit.net
        • Ron Jeffries
          ... The teams I have worked with can estimate things at a rate of several hundred per day, so I would think that if all you need is an estimate, you could just
          Message 4 of 22 , Apr 6, 2004
            On Tuesday, April 6, 2004, at 5:58:14 PM, Claude Montpetit wrote:

            > Implementing Scrum is very new to me and I am not sure about how to
            > deal with, for example, urgent estimates that must enter the current
            > sprint. Telling the salesman to wait for the next iteration for the
            > quote is not usually a good thing as it means that the implementation
            > would in theory start very late:

            The teams I have worked with can estimate things at a rate of several
            hundred per day, so I would think that if all you need is an estimate, you
            could just wander in and ask. But of course there's this pig / chicken rule
            in Scrum, so I don't know what the official answer should be.

            On the other hand, my experience with sales people suggests that often
            things need not be as urgent as they tend to be described ...

            Ron Jeffries
            www.XProgramming.com
            Fear is the mindkiller. --Bene Gesserit Litany Against Fear
          • Mike Cohn
            If these are truly one or two at a time I handle them in the next morning s Daily Scrum. We ll do the Scrum meeting as normal then everyone will stay for a few
            Message 5 of 22 , Apr 6, 2004
              If these are truly one or two at a time I handle them in the next morning's
              Daily Scrum. We'll do the Scrum meeting as normal then everyone will stay
              for a few minutes and we'll estimate a story or two from the previous day or
              that came up early in the morning.

              We routinely also slip in an occasional one-hour estimating session in each
              sprint just to look outward at future stories. That will eventually stop but
              we're working through a large backlog of unestimated stories.

              --Mike Cohn
              Author of User Stories Applied for Agile Software Development
              www.userstories.com

              -----Original Message-----
              From: Ron Jeffries [mailto:ronjeffries@...]
              Sent: Tuesday, April 06, 2004 6:04 PM
              To: scrumdevelopment@yahoogroups.com
              Subject: Re: [scrumdevelopment] Scrum and requirements (was Re: SCRUM
              process with other methodologies)

              On Tuesday, April 6, 2004, at 5:58:14 PM, Claude Montpetit wrote:

              > Implementing Scrum is very new to me and I am not sure about how to
              > deal with, for example, urgent estimates that must enter the current
              > sprint. Telling the salesman to wait for the next iteration for the
              > quote is not usually a good thing as it means that the implementation
              > would in theory start very late:

              The teams I have worked with can estimate things at a rate of several
              hundred per day, so I would think that if all you need is an estimate, you
              could just wander in and ask. But of course there's this pig / chicken rule
              in Scrum, so I don't know what the official answer should be.

              On the other hand, my experience with sales people suggests that often
              things need not be as urgent as they tend to be described ...

              Ron Jeffries
              www.XProgramming.com
              Fear is the mindkiller. --Bene Gesserit Litany Against Fear



              To Post a message, send it to: scrumdevelopment@...
              To Unsubscribe, send a blank message to:
              scrumdevelopment-unsubscribe@...
              Yahoo! Groups Links
            • Claude Montpetit
              Just in case it was misunderstood, what I was referring to in my post were not the usual product backlog estimates, but estimates used to establish a fixed
              Message 6 of 22 , Apr 6, 2004
                Just in case it was misunderstood, what I was referring to in my post
                were not the usual product backlog estimates, but estimates used to
                establish a fixed price bid for some requested product extensions.
                Because they are for fixed price extensions, these estimation
                requests become stories on their own as opposed to the rough estimates
                that we set on most stories that enter the backlog.

                (I have personnally never worked on a team that can produce such
                estimates at a rate of hundred per day... must be great though ;)

                Claude

                --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
                <ronjeffries@X...> wrote:
                > On Tuesday, April 6, 2004, at 5:58:14 PM, Claude Montpetit wrote:
                >
                >>Implementing Scrum is very new to me and I am not sure about how to
                >>deal with, for example, urgent estimates that must enter the current
                >>sprint. Telling the salesman to wait for the next iteration for the
                >>quote is not usually a good thing as it means that the implementation
                >>would in theory start very late:
                >
                >The teams I have worked with can estimate things at a rate of several
                >hundred per day, so I would think that if all you need is an
                estimate, you
                >could just wander in and ask. But of course there's this pig
                > / chicken rule in Scrum, so I don't know what the official answer
                should be.
                >
                >On the other hand, my experience with sales people suggests that
                >often things need not be as urgent as they tend to be described ...
                >
                > Ron Jeffries
                > www.XProgramming.com
                > Fear is the mindkiller. --Bene Gesserit Litany Against Fear
              • Ron Jeffries
                ... Yes. If it s a whole product, that would take a half-day or a day. I m talking about story estimates. If the group is commonly called upon to do that, I
                Message 7 of 22 , Apr 7, 2004
                  On Tuesday, April 6, 2004, at 11:33:23 PM, Claude Montpetit wrote:

                  > Just in case it was misunderstood, what I was referring to in my post
                  > were not the usual product backlog estimates, but estimates used to
                  > establish a fixed price bid for some requested product extensions.
                  > Because they are for fixed price extensions, these estimation
                  > requests become stories on their own as opposed to the rough estimates
                  > that we set on most stories that enter the backlog.

                  > (I have personnally never worked on a team that can produce such
                  > estimates at a rate of hundred per day... must be great though ;)

                  Yes. If it's a whole product, that would take a half-day or a day. I'm
                  talking about story estimates.

                  If the group is commonly called upon to do that, I guess I'd just plan for
                  it in the team's velocity.

                  Ron Jeffries
                  www.XProgramming.com
                  Accroche toi a ton reve. --ELO
                Your message has been successfully submitted and would be delivered to recipients shortly.