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

7911Re: [scrumdevelopment] Scrum Projects using tools

Expand Messages
  • Mike Cohn
    Jun 16, 2005
      Re: [scrumdevelopment] Scrum Projects using tools I always have teams allot some amount of time to “grooming the product backlog” to make sure it’s ready for the next sprint. So I’ve probably never done what Jeff is calling Type A. That may be why I’ve heard him refer to Type A teams who sprint for a month then spend 2 weeks between sprints getting ready to sprint again. Again, that’s something I’ve never done. In my world we go from sprint to sprint to sprint.

      5% for a full team is probably what I see and encourage. I give examples of an analyst or UI designer spending 10% of their time ahead. (Knowing that when I say 10% is OK they’ll do 20%)  Programmers typically spend around 2% (typically up to 2 hours of estimating or talking about future stories in one or two meetings). Testers will spend a bit more, probably 5-10% because I want them to help make sure the product owner has identified acceptance criteria (“conditions of satisfaction”) for the product backlog items we’re pretty sure are going to be selected for the next sprint.

      -Mike


      On 6/16/05 10:30 AM, "Ken Schwaber" <ken.schwaber@...> wrote:

      Mike,
      Think of A as a regular Scrum the way we know it. Think of B as the 5% set aside that I recommend teams use in Sprint-1 to estimate the upcoming backlog for a Sprint,
      Ken
       


      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Mike Cohn
      Sent: Thursday, June 16, 2005 10:39 AM
      To: Scrumdevelopment
      Subject: Re: [scrumdevelopment] Scrum Projects using tools

      “Continuous Sprints” are a bad idea. They go against two of the key points that make Scrum work in my opinion:

      1) Teams make commitments and then strive to meet them
      2) Work in process is reset to 0 at the end of every sprint

      As to #1, there is a huge value in saying “In a month we’ll be done with this.” It’s been shown (Teamwork, Larson and LaFasto) that teams do best when they have a “clear, elevating goal” and a “unified commitment” to meeting that goal. Working in 2-4 week sprints achieves that. That isn’t achieved with 1-day/continuous sprints.

      For #2: At the end of each sprint the sprint backlog is swept clean and we start with no work in process (WIP). Letting WIP build up will slow a process (software process, manufacturing process, etc.). We know this from Lean and from Theory of Constraints. Resetting WIP to 0 and allowing it to be brought again into the next sprint is one of the reasons Scrum works so well.

      I admit to being confused by the whole “Type C” concept as it seems based on a misinterpretation of the original Takeuchi and Nonaka paper. In that paper they drew “Type C” and that was Scrum. The Type A and Type B drawings were of a pure waterfall (“relay race”) approach (Type A) and then a moderate overlap of phases (B). Type C is Scrum. In that paper it is defined as “where the overlap extends across several phases.”
      So:
      Type A = Waterfall
      Type B= when sequential phases overlap some (analysis overlaps design but not coding; design overlaps coding but not testing)
      Type C = when the overlap is 2 or more phases (analysis overlaps at least design and coding but maybe not testing, per the paper)

      Because in Scrum we overlap all activities, Scrum is already beyond “Type C”


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




      On 6/16/05 8:15 AM, "Ken Schwaber" <ken.schwaber@...> wrote:
      I still like the monthly iteration because of the amount of functionality that can be created and the way it fits into the rest of the business cycle (sales, inventory, financial). I will follow this trend with interest over the upcoming years and see how it plays out.  I suspect that I’ll see most organizations continue to use monthly Sprints, and those that are the real competitors and engineers use shorter and shorter Sprints until they have continuous Sprints as described by Jeff Sutherland in Scrum Type C.
      Ken
       



      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] <mailto:scrumdevelopment@yahoogroups.com%5d> On Behalf Of Mike Cohn
      Sent: Wednesday, June 15, 2005 6:47 PM
      To: Scrumdevelopment
      Subject: Re: [scrumdevelopment] Scrum Projects using tools

      Ron--
      I find that when a team starts with Scrum they will ask the first of these
      questions ("how do we plan for defects coming back on us?") but after
      they've become accustomed to it they start to ask the second ("how do we
      make sure that defects do not escape the Sprint").

      I think teams need to learn to work in short iterations. Then they realize
      they need to change some engineering practices in order to work well in
      short iterations. That's what leads them to test-driven development, pair
      programming and such.

      Listening for when a team starts to ask the same question in a slightly
      different way is key in assessing how quickly they are adopting Scrum.


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




      On 6/15/05 4:31 PM, "Ron Jeffries" <ronjeffries@...> wrote:

      > On Wednesday, June 15, 2005, at 6:23:25 PM, Mike Beedle wrote:
      >
      >> In every situation, Scrum adapts and provides a balanced solution,
      >
      > I'm all for adapting, and as soon as I finish writing this note,
      > I'll face East and abase myself before the almighty Scrum.
      >
      > While defects do arise, it seems to me that the discussion focuses
      > more on "how do we plan for defects coming back on us" and less on
      > "how do we make sure that defects do not escape the Sprint" than
      > might be ideal.
      >
      > But that's OK.
      >
      > Ron Jeffries
      > www.XProgramming.com
      > You have to either laugh or cry.  -- Bill Rogers
      >
      >
      >
      > To Post a message, send it to:  scrumdevelopment@...
      > To Unsubscribe, send a blank message to:
      > scrumdevelopment-unsubscribe@...
      > Yahoo! Groups Links
      >
      >
      >
      >  
      >




      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@...


      Yahoo! Groups Links





      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@...



      Yahoo! Groups Links


    • Show all 51 messages in this topic