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

Re: [scrumdevelopment] Digest Number 777

Expand Messages
  • David A Barrett
    Mark, ... You may choose not to view it as a 90 day sprint, but if it quacks and waddles, then... To me, one of the benefits of Scrum is that it ensures that
    Message 1 of 1 , Nov 11, 2004

      >I simply do not view our cycle as a 90 day sprint. The pre-planning
      >process is outside the sprint. The goal is to get a reasonable set of
      >high-priority items into the product backlog, so the teams can get a
      >running start at the beginning of the sprint.

      You may choose not to view it as a 90 day sprint, but if it quacks and
      waddles, then...

      To me, one of the benefits of Scrum is that it ensures that the team is
      always focused on items that the customer has determined that to be of a
      high priority. Furthermore, the customer gets constant, timely feedback on
      the activities of the team. If the pre-planning is happening outside of a
      Sprint, then where are your controls to ensure that they aren't wasting
      time working on low priority items or going off in the wrong direction

      From my point of view, activities outside of a Sprint are "chaos". I want
      to pull as much of the team's work inside my Sprints so that they are
      properly controlled. It's NOT A GOOD THING to have your analysis happening
      outside of a Sprint.

      >Scrum does not state how long it takes, or by what process, a feature
      >gets inserted into the backlog.

      Actually, it does. Anyone can add anything to the PB at any time. It
      takes about as long as you need to ask for something.

      What I think you're actually talking about is the prioritization process
      and the inclusion of a PB item in a Sprint Backlog. Once again, these are
      very well defined. The Product Owner has sole responsibility for assigning
      priorities. Determination of the Sprint Backlog is supposed to happen in a
      4 hour Sprint Review meeting. Furthermore, there isn't supposed to me more
      than 1/2 hour preparation done for the Sprint Review meeting.

      Back to the prioritization. Practically speaking, most product owners need
      some estimate of the cost or time required to complete a PB item in order
      to set the priority. My experience is that a BOOM estimate is good enough
      for this purpose. Most Product Owners could care less if a PB was going to
      take 37.5 hours to complete or 39 hours; "something like 5 days" is good
      enough for setting priorities.

      As to the post development activites: It sounds to me more like you are
      doing Release activities than plain testing. Do you really do 30 days of
      testing for each 30 days of development (I know, times 12 teams)? Do you
      really deploy to dozens of external customers each month? Are you
      deployment activities really an empirical process, or is it pretty much
      defined by now?

      Regardless, what would happen if you shrunk the amount of programming being
      done each month down by 1/3, allowed for all of the analysis to happen in
      the same Sprint as the development and then tested in the same Sprint?
      Now, that would be Scrum.

      Anyways, at this point we've clearly gone past discussion and moved into
      holy war. Do what you want, call it what you want. Have lots of success
      with it.

      Dave Barrett,
      Lawyers' Professional Indemnity Company
    Your message has been successfully submitted and would be delivered to recipients shortly.