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

RE: [scrumdevelopment] Re: Scrum // Respect

Expand Messages
  • Paul Hudson
    We got into this discussion because you were saying the PO can or should dictate the sequence in which sprint backlog items get done. If there R S T W X Z, and
    Message 1 of 224 , Nov 1, 2008
    • 0 Attachment


      We got into this discussion because you were saying the PO can
      or should dictate the sequence in which sprint backlog items
      get done. If there R S T W X Z, and W is in the "must haves", the
      PO can or should say to implement them in order W X Z T R S.
      I'm busy disagreeing with that.

      I’ve looked back at my replies and I don’t think I said exactly that. I do think the PO should give an idea of what stories are most important and should be done first, just in case should things  go awry,. I’ve agreed that MoSCoW prioritisation would be enough, for instance.

      Mostly, I’ve been arguing it is reasonable to assume up front that the team MAY not meet their commitment, and it is reasonable to organise things in advance to cater for this possibility, rather than wait until the team have recognised that things aren’t going to plan

      But when you say, "Wouldn't you like it completed as the first
      thing done?", I hear you disagreeing with me and I disagree back -
      No, I really don't care if it's the first thing done or not,
      so long as it's done in time.

      In other words, for me, there is an enormous difference between
      those two phrasings - they aren't close synonyms to my eyes, they
      are dramatically opposed.

      But I didn’t say the second. I said “Wouldn't you like to have completed it first?”, meaning beforehand. I  understand that you reasonably enough interpreted as the second, but it really isn’t what  I meant.

      When I ask the kids if they’d like to eat first before going the cinema, I don’t mean that do they want to eat as the first thing they do next, just asking about the order of the two things.

      Bearing that in mind, what is it you would like to assert?
      Either we'll find that we really disagree, or we'll find we
      agree but have been running into a word clash.

      So, I think we’re probably running into  a word clash. My (apparently poorly expressed) point  for the last few rounds has been the one above – it is reasonable for the PO to assume the team MAY not meet their commitment, and  say what they’d like to be done should things go wrong, and that this has to happen before things do go wrong.

      One reason I’m slightly surprised by the idea that it’s somehow unfair/unreasonable/counterproductive to allow for the possibility that the team won’t mean their commitment is that to me, one of the reasons why Agile methods work as well as they do is they do consciously deal with the fact that in software development, plans often do go wrong – we don’t know now how to plan the development because the customer doesn’t know what we want, any plans we do have will change because the customer’s ideas of what they want will change, when we give them something their ideas will change again. When we’re estimating, we’ll find our estimates wrong.

      I see nothing especially different about assuming that the team’s commitments may also turn out not to be deliverable in practice. Given that, an Agile method should deal with the fallout of that – one way is to reduce the sprint length (so the opportunity to revise and correct direction is as soon as possible), but another seems to me to be to say something about the relative importance of the stories in a sprint, up front.

      Paul.

    • Doug Swartz
      ... XP differs from kanban in many of the same ways as Scrum. It is batch pull, not continuous pull. Instead of a sprint, XP calls it an iteration. In XP, like
      Message 224 of 224 , Nov 19, 2008
      • 0 Attachment
        Wednesday, November 19, 2008, 3:05:08 PM, Dillon Weyer wrote:

        > In this case how is XP different to Kanban then?

        XP differs from kanban in many of the same ways as Scrum. It
        is batch pull, not continuous pull. Instead of a sprint, XP
        calls it an iteration. In XP, like scrum, but not kanban, each
        story has a high level estimate attached to it during release
        planning, which is similar, but somewhat different from
        backlog grooming in scrum.

        Doug Swartz


        > aacockburn wrote

        > --- In scrumdevelopment@yahoogroups.com
        > <mailto:scrumdevelopment%40yahoogroups.com> , Graeme Matthew <scrum@...>
        > wrote:
        >>
        >> Whats the difference between a product backlog and kanban they both
        > act
        >> as signaling system to trigger action?
        >>
        >>

        > The kanban is continuous pull, the backlog is batch pull.

        > With the backlogs, each month you *promise* how much you'll do, and
        > pull a *batch* of items from the product to the sprint backlog.
        > You're now locked.

        > With kanban, you pull directly from the product backlog to the
        > work list, one at a time. There is no work estimate attached to the
        > item - you just work on it till you're done, then pull the next.
        > Some teams put size limits on the work list, so you can't work on
        > more than e.g. 5 items at a time.

        > That's quite a difference.

        > Alistair
      Your message has been successfully submitted and would be delivered to recipients shortly.