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

RE: [scrumdevelopment] Re: Managing the Scrum backlogs...

Expand Messages
  • Mike Cohn
    Exactly. We don t bother thinking much about distant requirements until we know they are either going into this sprint or will *definitely* go into a release
    Message 1 of 15 , Jun 30, 2003
    • 0 Attachment
      Exactly. We don't bother thinking much about distant requirements until we
      know they are either going into this sprint or will *definitely* go into a
      release (even if perhaps 3 sprints out).

      -Mike

      -----Original Message-----
      From: Ken Schwaber [mailto:ken.schwaber@...]
      Sent: Monday, June 30, 2003 9:08 AM
      To: scrumdevelopment@yahoogroups.com
      Subject: RE: [scrumdevelopment] Re: Managing the Scrum backlogs...

      As requirements rise in the priority of the product backlog, they are
      usually thought through more. As they are thought through more, they become
      more granular. High priority product backlog rarely are more than 10 days.
      If a high priority product backlog is 100 days, think it through more and
      break it down. If it is low priority, then 100 days is not rare.
      Ken

      -----Original Message-----
      From: JIM WIESEN [mailto:jwiesen@...]
      Sent: Monday, June 30, 2003 10:51 AM
      To: 'scrumdevelopment@yahoogroups.com'
      Subject: RE: [scrumdevelopment] Re: Managing the Scrum backlogs...


      I'm a little confused about how to handle product backlog tasks that are say
      100 days in duration. If the team is supposed to pick items off of the
      product backlog to add into a sprint, how do we handle something like this?
      We obviously can't complete a 100 day task in 30 days. Should the task be
      broken down into sub-30 days items, or should we take the task as a whole
      and add anything that is going to be unfinished back to the product backlog?


      -----Original Message-----
      From: Mike Cohn [mailto:mike@...]
      Sent: Friday, June 27, 2003 9:42 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: RE: [scrumdevelopment] Re: Managing the Scrum backlogs...

      First, you need to understand a couple of fundamental things about Scrum so
      you can understand the rest:

      a) Scrum requires self-organizing teams. So, there is no allocation of tasks
      during meetings. No, "Steve, you add support for...". Instead, team members
      sign up for tasks.

      b) In general, team members sign up for a task the day they start it, not in
      advance. So, there's no real need to "sort on priority" or search for
      assigned tasks, etc. During a sprint planning meeting a team will typically,
      to some extent, "pre-signup" for work so they can determine if they're
      bringing the right amount of work into the sprint. But that changes day to
      day (perhaps not really during the first week or so) as learning about the
      tasks occurs.

      c) As others and I have said there are two backlogs: product and sprint.
      Product backlog items might be "high level items" but sprint backlog are
      tasks (not requirements per se) and are rarely more than 16 hours. Product
      backlog items may be huge--I'll routinely have some big product backlog
      tasks that we can't assess well (and time isn't worth spending on such an
      effort). Those may be in as 100 days, for example.

      d) The person working on a task (definitely never an "assignee") goes to the
      "Product Owner" to find out the requirements. A Scrum team could perhaps use
      a document to reflect the requirements of a given sprint but they are
      generally trying to move too quickly and will instead prefer verbal
      communication, much as with any of the other agile processes.

      As to a lightweight tool: I'm intrigued by the use of tools for this purpose
      but not so much for the day to day tracking of work left on a task or within
      a sprint. The real value would more likely be found in organizing product
      backlog items into release plans and also into being able to look back at
      those over time. For example, we'll often start what we know will be a
      multi-month project with just enough requirements to do the first sprint
      (month). During the first month the Product Owner loads up the Product
      Backlog. After a month we may work with the PO and determine an approximate
      place we'll get to by the 5th sprint, at which point we'll release. But,
      then after 4 months we might still be two (instead of 1) sprint away. It
      would be nice to have a product that could show me (in soft of a visual diff
      way) all the requirements that changed in priority, estimate, or are new.
      That's the type of thing that is a bit hard in Excel. (I do it in Excel by
      using a version control system, exporting spreadsheets to CSV files and then
      using WinMerge as a good visual differencing tool).

      I hope that helps,

      -Mike

      -----Original Message-----
      From: bannerma [mailto:steve.bannerman@...]
      Sent: Friday, June 27, 2003 8:00 AM
      To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] Re: Managing the Scrum backlogs...

      Rick,

      Thanks for your answers...replies below:

      --- In scrumdevelopment@yahoogroups.com, Rick Innis <rick@i...>
      wrote:
      > .
      > .
      > .
      >
      > Again as I understand it, managing the backlog is part of the
      > ScrumMaster's job. The daily scrum is an important part of
      managing the
      > backlogs because it's the mechanism the ScrumMaster uses to track
      > progress.
      >

      Okay, so are you saying that the team members don't need to have
      access to the backlog, look at changes to it, filter for things
      assigned to them (if indeed that is tracked), sort on priority,
      etc...

      >From my experience, a standup (which I've advocated and practiced
      for many years) is a great opportunity to communicate at a high
      level, identifying who needs to work on what and who needs to work
      together that day (since there are interdependencies).

      However, what gets allocated during standups is usually at that high
      level. "Steve, you add support for creating a switch, including
      automated tests that test it." The details of what it means to
      create a switch are not communicated (otherwise the standups are a
      lot longer than 15 minutes).

      So is it correct to say that the backlog contains those high level
      items (high level requirements)? If so, where does the assignee go
      to get the details? Wouldn't it be nice to be able to use that high
      level item itself as a portal to the details?

      > To track the backlogs overall, an Excel spreadsheet is
      surprisingly
      > useful. One of the beauties of Scrum is that it only requires
      > lightweight management tools!

      Sure, I know that Excel spreadsheets are incredibly useful.
      However, I really think that using them for requirements is
      capturing them at the wrong level of granularity (i.e. one file for
      a set of requirements).

      Couldn't there also be a "lighweight" tool that manages the
      requirements one per file? My experience with Excel is that it's
      great for initial tasks but as "things" change (and they always do)
      it's difficult to tell what exactly has changed.

      What does a "lightweight" tool mean to you (and others in the group)?

      Looking forward to your response(s).

      Cheers

      >
      > --Rick



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

      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/




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

      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/




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

      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/




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

      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
    Your message has been successfully submitted and would be delivered to recipients shortly.