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

Nitty-gritty detail of updating Scrum artifacts

Expand Messages
  • paulsiu1887
    Many of the Scrum books describe the process of how Scrum works very well, but few seem to include the Scrum artifacts and how to use them. What I really want
    Message 1 of 59 , Jun 24, 2006
    • 0 Attachment
      Many of the Scrum books describe the process of how Scrum works very
      well, but few seem to include the Scrum artifacts and how to use
      them. What I really want is the nitty-gritty details of how to use a
      spreadsheet program to track project detail. Bear in mind that I am
      new to this. I have search the archives but did not find a
      definitive answer.

      The three artifacts for Scrum are the Product Backlog, Sprint
      Backlog, and burn down chart. For the product backlog, I enter all
      of the task that might be done. This spreadsheet would contain:

      ID - some independant unique ID.
      Description - description of of the task.
      Person - person doing the task.
      Estimate - estimate of the task.
      Sprint - the sprint the item is assigned to.

      Person, estimate, and sprint are assigned only when the task is
      entered into a sprint.

      As for the product backlog, I copy the items into a separate
      spreadsheet and create a bunch of columns to represent the days in
      the sprint. I then fill right on the estimates so that they copy the
      estimates value to the end of the sprint. As developers work on the
      task, they remove hours per day until they are done. The graph will
      reflect the daily completions. Howver, I get stuck with the
      following problem.

      1. Product Backlog becomes much too long. Do people add a status
      column so that they can filter out items that are done?

      2. Suppose developers notice that a task actually take shorter than
      estimate, how is this handled? Example: developer estimate task A
      will take 16 hours. It is marked as 16 hours remaining on Monday.
      The next day, the developer works on it and realizes that it is
      actually a 4 hour task, does the developer just change the hours
      remaining to zero on Tuesday (I assume yes)?

      3. Suppose the developer notice the task actually take longer. Does
      the developer actually add hours to the hours remaining on the day
      that it was discovered?

      4. One question often asked is, do we have enough work for each of
      the developers. Using the person and the estimate, one can calculate
      how many hours each person is working on in the sprint. However,
      estimate are likely to be off, and so may be the task should be
      assigned to someone else if one person's plate becomes too full.
      Should I add an actual column next to the estimate that start out
      with the estimate value but is revised as the project progress? Is
      there a better way of doing this?

      5. A similar quesition is to track estimate vs actual. The idea is
      that we can check if we are experiencing a pattern where we
      consistently underestimate or overestimate. Does anyone have any
      idea how to track this? Separate est and actual columns, etc.

      Thanks.

      Paul
    • Steven Gordon
      When I read about an organization with rampant context switching, siloing and resource fragmentation, I believe it is management s responsbility to figure out
      Message 59 of 59 , Jul 4, 2006
      • 0 Attachment
        When I read about an organization with rampant context switching,
        siloing and resource fragmentation, I believe it is management's
        responsbility to figure out how to address the organizational
        dysfunctions rather than blame the developers for not being able to
        commit to what they can get done in short time frames under such
        circumstances.

        To say that the problem appears to be that the developers are slacking
        off exhibits so much arrogance on the part of management, my gut
        reaction is to suggest that if management has no more problems to
        solve and yet the development throughput is unsatisfactory, then maybe
        the organization needs less managers and more developers.

        Steven Gordon

        On 7/4/06, Wolfgang Schulze Zachau <wolfgang@...> wrote:
        >
        >
        >
        >
        >
        >
        >
        > The unfortunate lad reports to a different team, and I am allowed to make
        > use of approx. half his time.
        >
        >
        >
        > I don't need to suspect. I *know* they all do things that are unrelated to
        > sprint. This is due to all of us having to do day-2-day IT support for
        > approx. 50-60 other staff (who range from almost complete computer
        > illiteracy to somewhat advanced homw users), plus everyone has their
        > personal career development objectives, which they need to spend 4 hours a
        > week on doing.
        > The support work is on average not enough to keep a full man busy, so we
        > have decided to rotate this around, then at least everybody gets 4 days of
        > relatively uninterrupted work per week.
        >
        >
        > Have you sat
        > > down with Jimmy and his partner and pointed out that they are
        > > failing to meet their commitments, and asked why?
        >
        > Yep, I have. And that's when the excuses come alive. Which is why I wanted
        > them all to report back how exactly they are using their time when not
        > working for the sprint.
        > There used to a habit here that other staff would just walk up to a member
        > of the IT team, state their demands/requirements/wishes and expect things
        > to
        > get done on the spot (supported to some degree by the MD himself). I have
        > pretty much stopped that and now at least these folks either go through me
        > or they log their work requests in the (ever popular) bug tracker, so that
        > we can prioritize them and then schedule them.
        > But then, we are an e-commerce company, our IT systems are the very blood
        > that keep this company alive. There are numerous justified occasions where
        > emergencies need to be responded to right away. I simply want them tracked.
        >
        >
        > Regards,
        >
        > Wolfgang
      Your message has been successfully submitted and would be delivered to recipients shortly.