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

Re: [scrumdevelopment] Big Picture at the Daily Scrum

Expand Messages
  • Kevin Dalley
    ... Yes, I think that there were separate tasks all along. There was one story initially, which was handed to me. Today, on the last day of the sprint, we
    Message 1 of 65 , Jun 3, 2006
    • 0 Attachment
      Mike Kenny <mike.kenny@...> writes:

      > On Thu, 2006-06-01 at 21:31 -0700, Kevin Dalley wrote:
      >> After some effort, I split mine into 4 tasks and started working on
      >> task 1.  This almost meets Ron's 1/5 suggestion. Initially, there was
      >> a feeling that I didn't need to stage the big task like this.
      >> However, after a day or two, 3 out of the 4 tasks were dropped from
      >> the sprint as unnecessary. Unfortunately, task 2 remained, and I had
      >> been working on task 1.
      > The fact that occasionally it is possible to split a large task into
      > smaller components isn't, of itself, that surprising. It often happens
      > that the granularity of the requirement is not appreciated until work
      > starts. What I do find amazing is that, having realized that the task
      > could be split into four it was then possible to drop 3 of these four.
      > To me this implies that the original large task was composed of
      > unrelated smaller tasks and that these should never have been seen as
      > inter-dependant.

      Yes, I think that there were separate tasks all along. There was one
      story initially, which was handed to me. Today, on the last day of the
      sprint, we discovered that the QA end to end test for this item
      doesn't quite test the task. Obviously, there is a desire to change
      the task.

      It's simple to say that the requirements shouldn't change during the
      sprint. However, there is a hard requirement that the requirements
      for a certain customer be ready for testing in 2 or 3 months. If the
      requirements are not met, the customer is lost. Unfortunately, the
      requirements are not well understand. 1 month sprints may not really
      leave enough time between sprints to adapt to our changing
      understanding of the requirements. On the other hand, changing
      requirements other day would be frustrating. What's the solution?
      One week sprints, then reevaluate every week. One day sprints?
    • Ilja Preuss
      ... I m not Hubert, but *we* are definitely burning *and working* backlog items. We still use tasks for estimation, and they seem to be helpful; but when we
      Message 65 of 65 , Jun 11, 2006
      • 0 Attachment
        > On Friday, June 9, 2006, at 7:49:00 AM, Hubert Smits wrote:
        >
        >> Ain't you also working down to zero /in a Sprint/? I have x folks who
        >> have y days remaining in the sprint, so I can burn x times y days. If
        >> the amount of work at any given day exceeds this number I have
        >> something to think about. I have to add though: I am thinking from
        >> 'pure scrum' perspective - no change of scope during the sprint.
        >
        > Don't your teams add and remove tasks during the sprint? Or are you
        > burning backlog items, even though the team is working tasks?

        I'm not Hubert, but *we* are definitely burning *and working* backlog items.
        We still use tasks for estimation, and they seem to be helpful; but when we
        try to work them, we almost invariably find that we need to break down the
        work differently from the breakdown for estimation, and that we can't really
        plan how to break the work itself down into meaningful tasks.

        Perhaps it's just us...

        Cheers, Ilja

        --
        "Information Radiation in Practice -
        Communication Tools for Colocated Teams"

        Tutorial at the XP2006 conference, Oulu
        www.xp2006.org
        17.06.2006
      Your message has been successfully submitted and would be delivered to recipients shortly.