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

Re: [scrumdevelopment] Big Picture at the Daily Scrum

Expand Messages
  • Tobias Mayer
    Hi Ronica, Great question. Here s my two cents. I rarely use task/hours burndown charts these days. I find them misleading. If a team makes good use of a
    Message 1 of 65 , Jun 1, 2006
    • 0 Attachment
      Hi Ronica,
      Great question.  Here's my two cents.
      I rarely use task/hours burndown charts these days.  I find them misleading.  If a team makes good use of a task board, the task board itself serves as the indicator of progress, far more effectively than a burndon chart.  Burdown charts abstract away the detail.  It is usually the detail of a task that is requiredto understand the type of delay that may occur.  By focussing on the tasks remaining each day, the team has a very clear picture of what they can and cannot achieve.
      I have also stopped using hours on tasks  I don't care (no one should) about how many hours are remaining on a particular task.  A task is either done or not done.  Not done tasks are just as not done if they have one hour remaining, than if they have eight.  Any task sitting in WIP for more than a day should raise a concern.
      The task board is the Big Picture.
      A sense of urgency, or a realistic re-scoping becomes unavoidable when the whole team can see a bunch of tasks in To Do and WIP with only a few days to go before the end of the sprint.
      A burndown chart that I have found useful is the Story Burndown.  Stories should be completed sequentially, as Victor pointed out earlier.  A healthy Story Burndown chart should show a series of regular steps going down.  Any long horiziontal line should raise a concern, and cause the team to consider de-scoping.
      The Scrum Master should encourage the team to commit to less if the team fails to deliver on more than one consecutive sprint.  Sometimes the team will do this for themselves, but more often that not, they need support in making that decision.  The task board greatly helps the team to become more self-managing, and thereby more accountable.

      Ronica Roth <ronicaroth@...> wrote:
      In the Burndown Chart discussion, Victor Szalvay < victor@...> wrote:
       If the team wants a trendline then again I think
      something is wrong because the team is asking for a crutch to tell
      them how things will turn out in the sprint.  In my experience, Scrum
      teams know how they are doing each day if there are well-run daily
      scrum meetings and generally good communication across the team.

      Which helped me finally nail down a question I've been trying to formulate. Our daily scrums have improved to the point where the team is communicating with one another (not at the scrummaster), and members are faithfully reporting what they did, will do, and problems. But I don't feel like they have any sense of whether they will succeed in completing the iteration. Despite burndown charts and the iteration dashboard (we use Rally), the amount of work *not* getting accomplished by the end of iteration always seems a huge surprise.

      How can one improve the team's sense of the big picture, as well as the urgency/commitment around completing the iteration?


      ironica99 (at) gmail (dot) com aka ronicaroth (at) earthlink (dot) net


    • 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
      Your message has been successfully submitted and would be delivered to recipients shortly.