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

Re: [scrumdevelopment] Big Picture at the Daily Scrum

Expand Messages
  • Hubert Smits
    Hi Ronica, Sounds like your developers don t realize what it means to be done with a story. I run a brief discussion around the definition o f done at the
    Message 1 of 65 , Jun 1, 2006
      Hi Ronica,

      Sounds like your developers don't realize what it means to be 'done' with a story. I run a brief discussion around 'the definition o f done' at the start of every planning meeting. Just to remind the folks that there is a lot more to do then moving code into the library. If you look through Jeans presentation you will find the example, otherwise let me know and I'll send you examples.

      Also: I politely disagree with Tobias, I think a burndown is a simple and effective way to learn how much work is left to do. If your team has a surprise at the end of the sprint, then the burndown should reflect this, or the update wasn't faithful (possible relation to the above). Can you tell us a bit more about why the burndown doesn't accurately reflect the remaining hours?

      And no disrespect to Tobias, we use different tools, all good carpenters love their own hammers :-)


      On 6/2/06, Tobias Mayer < tobyanon@...> wrote:
      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


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




      All opinions in this message are my own, and are not necessarily shared by my employer.
    • 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
        > 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.