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

RE: [scrumdevelopment] Re: Scrum in 2003

Expand Messages
  • Charlie Trainor
    Jens, It sounds like you will have better success if you can break down the backlog items into smaller pieces of useful functionality that are easier to grasp,
    Message 1 of 6 , Dec 17, 2003
      Jens,
       
      It sounds like you will have better success if you can break down the backlog items into smaller pieces of useful functionality that are easier to grasp, and take a more evolutionary approach to design.  Something like "must have perfect history" might be the vision, but you may want to do it in multiple stages (eg start with one type of history entry, or start by ignoring some aspects of the "extra dimension" that adds complexity in your case).  Of course, you want to find subsets of the "perfect history" feature that can be meaningfully demonstrated to the customer.  Each subset is easier to design and implement, so there will be less feeling of chaos and uncertainty.
       
      Your statement that "architectural issues have to be correct" is not shared by the XP community.  Architecture can evolve, and at any point it only has to be good enough to handle the backlog items you have implemented.
       
      - Charlie
      -----Original Message-----
      From: je@... [mailto:je@...]
      Sent: December 17, 2003 8:19 AM
      To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] Re: Scrum in 2003

      --- In scrumdevelopment@yahoogroups.com, deborah@h... wrote:
      > This is the second time I've seen mention here of "chaos in week 1"
      > and it surprises me... are the items in your backlog <= 16 hours,
      as
      > recommended? If so, shouldn't chaos last only hours at a time?

      Hi Deb

      I do belive our chaos (complexity) is due to the fact that we have
      not had proper backlogs. This would mean that things are not thought
      thru, before, the making of the sprintlog.

      For instance, in one of the sprints there were an activity which
      read "must have perfect history". We all know this can be a
      challenge, and this particular system had an extra dimension. The
      team set aside hours for analysis, db modelling, etc. After 3 days
      the team sees that there solution is not good enough. They have to
      start over, putting more hours in the sprintlog, etc, and the team
      worries. Archtectural issues are hard to estimate since they have to
      be correct. If there had been a proper backlog, the history problem
      would have been thought about before the sprint, informal discussions
      had been held, etc. There chances of designing a good history system
      quicker, would have increased.

      In the next sprint we will have a proper backlog, and I am curious
      how that will effect the sprint.

      Jens

    Your message has been successfully submitted and would be delivered to recipients shortly.