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

RE: [scrumdevelopment] Re: Sprint Burndown Chart

Expand Messages
  • Jeff Heinen
    I think it s important to recognize that the commitment in scrum is two-way. The team commits to achieving the goals by the end of the sprint, and the Product
    Message 1 of 32 , Mar 2 11:59 AM
    • 0 Attachment
      I think it's important to recognize that the commitment in scrum is
      two-way. The team commits to achieving the goals by the end of the
      sprint, and the Product Owner commits to not interfering with how the
      team goes about achieving those goals or introducing change within the
      sprint. Each of those commitments is built on trust; the PO must trust
      that the team will do the best they can possibly do under the
      circumstances to achieve the goals, and the team must trust that the PO
      will not change the goals during the sprint. High-bandwith communication
      and visibility is extremely important, however I think that sometimes
      communication can morph into coercion if trust is not established, and
      when that happens trust only erodes further. The scrum master's duty is
      to facilitate the communication between the team and the stakeholders so
      that well-intentioned communication does not devolve into coercion and
      distrust.

      > -----Original Message-----
      > From: scrumdevelopment@yahoogroups.com
      > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Ilja Preuss
      > Sent: Thursday, March 02, 2006 7:25 AM
      > To: scrumdevelopment@yahoogroups.com
      > Subject: RE: [scrumdevelopment] Re: Sprint Burndown Chart
      >
      > >>> The product owner should judge according to what is
      > delivered at the
      > >>> Sprint Review Meeting rather than what transpires during
      > the Sprint.
      > >>
      > >> What is wrong with the product owner caring about what
      > happens during
      > >> the sprint?
      > >
      > > Probably nothing once you have established mutual trust.
      > But excess
      > > scrutiny during the sprint can inhibit the team's self-organization
      > > when the product owner and team are trying to break a cycle of
      > > micromanagement and intimidation. We once had to ask a P.O. (who
      > > happened to be everyone's boss) to give his teams more
      > privacy during
      > > Sprint execution. His mere presence was a distraction to
      > government
      > > employees who were used to being treated like kindergarteners.
      > >
      > > I know this sounds like it goes against "visibility" but it's what
      > > that situation called for.
      >
      > Well, perhaps it was called for in that specific situation.
      >
      > Your statement above sounded more general to me. And in
      > general I would argue that it is *more* communication which
      > establishes trust, not *less*.
      >
      > > As discussed earlier, we sometimes see ScrumWorks users
      > whose Sprint
      > > Burndown Charts go down in a perfect straight line. This
      > suggests to
      > > me people are more concerned with looking good for someone than
      > > reestimating honestly.
      >
      > Sounds like a reasonable assumption.
      >
      > > If they know
      > > their performance will be assessed by what their team actually
      > > delivers they'll be more comfortable giving honest estimates to
      > > facilitate team self organization.
      >
      > Agreed.
      >
      > And the assessment will be better, and thereby more trust be
      > established, the better they meet the product owners
      > expectations - and they will be in a better position to meet
      > expectations the *more* they are communicated, as far as I can tell.
      >
      > Cheers, Ilja
      >
      >
      >
      > To Post a message, send it to: scrumdevelopment@...
      > To Unsubscribe, send a blank message to:
      > scrumdevelopment-unsubscribe@...
      > Yahoo! Groups Links
      >
      >
      >
      >
      >
      >
      >
      >
      >
    • Ilja Preuss
      ... I m not a Scrum expert, so I m not sure what Scrum is saying about it. From my point of view, though, I certainly agree that it s not good if the product
      Message 32 of 32 , Mar 2 11:38 PM
      • 0 Attachment
        > I think it's important to recognize that the commitment in
        > scrum is two-way. The team commits to achieving the goals by
        > the end of the sprint, and the Product Owner commits to not
        > interfering with how the team goes about achieving those
        > goals or introducing change within the sprint. Each of those
        > commitments is built on trust; the PO must trust that the
        > team will do the best they can possibly do under the
        > circumstances to achieve the goals, and the team must trust
        > that the PO will not change the goals during the sprint.
        > High-bandwith communication and visibility is extremely
        > important, however I think that sometimes communication can
        > morph into coercion if trust is not established, and when
        > that happens trust only erodes further. The scrum master's
        > duty is to facilitate the communication between the team and
        > the stakeholders so that well-intentioned communication does
        > not devolve into coercion and distrust.

        I'm not a Scrum expert, so I'm not sure what Scrum is saying about it.

        From my point of view, though, I certainly agree that it's not good if the
        product owner *interfers* with the work of the developers. On the other
        hand, he has information that the developers would be well adviced to listen
        to not only at the start and the end of the sprint. And he has expectations
        that are better aligned with what the team can deliver more often than once
        every three weeks.

        So I'd want the whole team to work on communicating *continouosly* in a
        non-"interfering", productive way.

        Perhaps there are situations where this is best achieved by reducing the
        amount of communication for a while. I just don't think it is a good idea to
        use this as a permanent solution, or the default behaviour of a team.

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