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

RE: [scrumdevelopment] SCRUM process with other methodologies

Expand Messages
  • Mike Cohn
    Michael-- For the most part you really want to do all that analysis work as part of the sprint. Keep in mind that requirements are like inventory and we don t
    Message 1 of 22 , Apr 5 5:49 PM
    View Source
    • 0 Attachment
      Michael--
      For the most part you really want to do all that analysis work as part of
      the sprint. Keep in mind that requirements are like inventory and we don't
      want to pile up too much inventory that may never turn into finished
      software. Plus, if you do it too soon you lose the ability to have new
      learning impact those requirements and the knowledge goes stale quite
      quickly. A couple of short, to-the-point, upfront conversations don't hurt
      but when you start writing it all down, referring back to it, pointing to it
      as though it means something, then you've done too much requirements work
      upfront.

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


      -----Original Message-----
      From: Michael Dowling [mailto:mdowling@...]
      Sent: Monday, April 05, 2004 1:48 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: Re: [scrumdevelopment] SCRUM process with other methodologies

      > Sounds like it would work for me, but why aren't the analysis and
      > artifact construction teaks part of the backlog so that they can be
      > prioritized with the rest?

      So, basically "Gather Requirements on Feature X" be a backlog item to be
      prioritized? That priority is implicit - engineering work cannot be
      done on a "feature" or "bug" without proper analysis (be it short or
      lengthy, depending on the organization and/or team). This is why I
      assume that a backlog item should already have gone through the
      requirements phase already - it is generally, almost always during this
      time that features and needs are found to be either a) necessary, b)
      unnecessary, or c) nifty, but not yet important. From there one can
      pass it to a backlog for prioritization, but only after knowing what the
      heck one wants.

      I know - this does sound a little waterfallish. But think of it this
      way - collaborative waterfall. JAD is similar to SCRUM whereas all
      members of a JAD team collaborate on the project. You're just
      "waterfalling" the collaboration from one phase to the next. And SCRUM
      allows for the (certain and expected) changes in those requirements.


      > Dan Rawsthorne, PhD, Sr. Consultant
      > www.netobjectives.com
      > DrDan@...
      > office: 425-269-8628

      Off-topic - hey - are you from the same group that did (does?) the
      lectures/seminars in Bellvue on proper design techniques? You guys did
      a fabulous job, and with each lecture I walked away with a new idea of
      better design. Do you ever hold these lectures in the SF Bay Area
      (yeah, had to return to San Francisco - Seattle was too wet for me! :) ).


      --

      Michael Dowling
      mdowling@...
      PlanetOut Partners, Inc.
      415.834.6500 main | 415.834.6306 direct | 415.834.6502 fax
      www.gay.com * www.planetout.com * www.kleptomaniac.com * www.outandabout.com



      To Post a message, send it to: scrumdevelopment@...
      To Unsubscribe, send a blank message to:
      scrumdevelopment-unsubscribe@...
      Yahoo! Groups Links
    • Dan Rawsthorne
      Yes, Analyze XXX is a backlog item. One wouldn t do it unless XXX had a high enough priority to do it, right? In a system where we think of 50 use cases up
      Message 2 of 22 , Apr 5 5:50 PM
      View Source
      • 0 Attachment
        Yes, "Analyze XXX" is a backlog item. One wouldn't do it unless XXX had
        a high enough priority to do it, right? In a system where we think of 50
        use cases up front we don't analyze all of them up front, we analyze
        them as we go.

        So, these analysis tasks must be on somebody's backlog. If that somebody
        is another, analysis, team, that's ok, but I prefer my team to be one,
        big, happy, one - including analysts, coders, testers, etc - with one,
        big, happy product backlog...

        Dan ;-)

        Dan Rawsthorne, PhD, Sr. Consultant
        www.netobjectives.com
        DrDan@...
        office: 425-269-8628

        Net Objectives' vision is effective software development without
        suffering. Our mission is to assist software development teams in
        accomplishing this through a combination of training and mentoring.


        > -----Original Message-----
        > From: Michael Dowling [mailto:mdowling@...]
        > Sent: Monday, April 05, 2004 1:48 PM
        > To: scrumdevelopment@yahoogroups.com
        > Subject: Re: [scrumdevelopment] SCRUM process with other methodologies
        >
        > > Sounds like it would work for me, but why aren't the analysis and
        > > artifact construction teaks part of the backlog so that they can be
        > > prioritized with the rest?
        >
        > So, basically "Gather Requirements on Feature X" be a backlog item to
        be
        > prioritized? That priority is implicit - engineering work cannot be
        > done on a "feature" or "bug" without proper analysis (be it short or
        > lengthy, depending on the organization and/or team). This is why I
        > assume that a backlog item should already have gone through the
        > requirements phase already - it is generally, almost always during
        this
        > time that features and needs are found to be either a) necessary, b)
        > unnecessary, or c) nifty, but not yet important. From there one can
        > pass it to a backlog for prioritization, but only after knowing what
        the
        > heck one wants.
        >
        > I know - this does sound a little waterfallish. But think of it this
        > way - collaborative waterfall. JAD is similar to SCRUM whereas all
        > members of a JAD team collaborate on the project. You're just
        > "waterfalling" the collaboration from one phase to the next. And
        SCRUM
        > allows for the (certain and expected) changes in those requirements.
        >
        >
        > > Dan Rawsthorne, PhD, Sr. Consultant
        > > www.netobjectives.com
        > > DrDan@...
        > > office: 425-269-8628
        >
        > Off-topic - hey - are you from the same group that did (does?) the
        > lectures/seminars in Bellvue on proper design techniques? You guys
        did
        > a fabulous job, and with each lecture I walked away with a new idea of
        > better design. Do you ever hold these lectures in the SF Bay Area
        > (yeah, had to return to San Francisco - Seattle was too wet for me!
        :) ).
        >
        >
        > --
        >
        > Michael Dowling
        > mdowling@...
        > PlanetOut Partners, Inc.
        > 415.834.6500 main | 415.834.6306 direct | 415.834.6502 fax
        > www.gay.com * www.planetout.com * www.kleptomaniac.com *
        > www.outandabout.com
        >
        >
        >
        > To Post a message, send it to: scrumdevelopment@...
        > To Unsubscribe, send a blank message to: scrumdevelopment-
        > unsubscribe@...
        > Yahoo! Groups Links
        >
        >
        >
        >
        >
        >
        > ______________________________________________________________________
        > This email has been scanned by the MessageLabs Email Security System.
        > For more information please visit http://www.messagelabs.com/email
        > ______________________________________________________________________
      • Ron Jeffries
        ... 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
        Message 3 of 22 , Apr 5 7:22 PM
        View Source
        • 0 Attachment
          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
        • Jens Ƙstergaard
          I ve used it before (and *adore* it), but some folks also want ... Basic ... Hi Michael I have had absolutely no problem using excel and find that it works vey
          Message 4 of 22 , Apr 6 12:23 AM
          View Source
          • 0 Attachment
            I've used it before (and *adore* it), but some folks also want
            > to take a look at some other tools (excel just doesn't cut it).
            Basic
            > requirement is that it be as simple as scrum itself.
            >

            Hi Michael

            I have had absolutely no problem using excel and find that it works
            vey well. If a team needs additional material for coordination, they
            figure it out themselves.

            If you sign in and look under files, I have posted an example of a
            sprintlog that we use.

            Jens
          • 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 5 of 22 , Apr 6 4:00 AM
            View Source
            • 0 Attachment
              --- 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 6 of 22 , Apr 6 8:42 AM
              View Source
              • 0 Attachment

                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 7 of 22 , Apr 6 2:58 PM
                View Source
                • 0 Attachment
                  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 8 of 22 , Apr 6 5:03 PM
                  View Source
                  • 0 Attachment
                    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 9 of 22 , Apr 6 7:07 PM
                    View Source
                    • 0 Attachment
                      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 10 of 22 , Apr 6 8:33 PM
                      View Source
                      • 0 Attachment
                        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 11 of 22 , Apr 7 3:25 AM
                        View Source
                        • 0 Attachment
                          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.