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

Re: Arguments for not using MoSCoW in Product Backlog List

Expand Messages
  • Joseph Little
    Hi mkg6, I don t disagree with what the others have said. AND...perhaps it is useful to look at this as a people issue. Or a change management issue. Let s
    Message 1 of 6 , Dec 17, 2007
    • 0 Attachment
      Hi mkg6,

      I don't disagree with what the others have said. AND...perhaps it is
      useful to look at this as a people issue. Or a change management issue.

      Let's call the systems integrator person Bob. You have not described
      Bob much. He could be in many situations. Maybe just wanting to feel
      a little important, more than anything else; seems a possibility.

      How do you gain, and Bob gain/lose by insisting on the intellectual
      purity of not using MoSCoW? How would you lose and Bob gain if you
      said something like..."In the immediate context, and not considering
      future learning, which will surely happen, the first X% of stories
      might be considered Musts, the next Y% of stories are Shoulds...(and
      so on)"?

      If this MOSCOW business is Bob's only objection to Agile/Scrum, then
      maybe it goes better in the long run not to pick a fight about that,
      but to come back later, when Bob sees better how Scrum handles change,
      and then say "...so how are you seeing now how Scrum and the PO and
      the Team manage the 4 triple constraints?" (I say it that way as a
      kind of joke, because usually the triple constraints include Time,
      Scope, Cost and Quality...so there are 4 of 'em.) Full Reality is a
      much better teacher than some small amount of hot air. You might save
      your influencing capital for a later investment. Don't give in, just
      maybe don't contend on this one.

      Influence Bob slowly. Change him slowly. (I have heard it said that
      the hardest thing about change is not the change itself, but being
      changed by another person(s).)

      NOW...having said all that, I can also imagine a situation (or 5)
      where having the philosophical discussion now might be a good thing.
      Part of the answer lies within yourself; why do you want to have
      this..."fight" perhaps? In your writing, you don't seem particularly
      emotional about things; nor does Bob. But you know the reality, and I
      know only what you wrote.

      If only coaching were simpler. I think it's all those darn pesky

      Maybe these comments help; if not you, then maybe another. Good luck,
      in any case.

      Regards, Joe

      Kitty Hawk Consulting
      Charlotte, NC

      PS. If I recall, MOSCOW is accepted within DSDM, which, last I looked,
      was still considered part of Agile. We have enough enemies already;
      don't see a need to add more without a compelling reason.

      --- In scrumdevelopment@yahoogroups.com, "mkg6_hotmail" <mkg6@...> wrote:
      > I've recently been appointed as 'Software Coach' for a small team.
      > I'm going to run the team as Scrum as possible. One thing it will not
      > be Scrum in is that I'm forced to be both the PO and SM. That sounds
      > a lot like traditional PM, and it is. However the entire project and
      > a lot in our organisation use traditional PM, being a small unit in
      > the project doesn't help. I feel that I have enough Scrum experience
      > to guard the two roles, although I feel more comfortable with the SM
      > than the PO part.
      > I have written a unit plan that I've kept as small as possible. I
      > basically explain the Scrum and Lean backgrounds that we'll be using
      > and I've included the release plan using an estimated velocity.
      > All fine so far and most people that have reviewed the document are
      > satisfied. However the system integrator requests me to add MoSCoW
      > priorities to the 'requirements'.
      > I don't want to, I feel that it doesn't help. The list is already
      > prioritized as much to 'value' as possible. Problem is that my unit
      > has to align with other units and that makes it not always possible
      > to prioritize purely on value.
      > Musts, Shoulds, Coulds are not static but vary over time, as a result
      > from the actual project execution, not my original plan. This it to
      > be reflected in the product backlog list for the current release. As
      > soon as my backlog list contains more than 110% items compared to the
      > estimated capacity (= velocity * sprints left) I want to trim down
      > the list, naturally leaving out the bottom.
      > Even 'musts' are not musts if the business unit wants to make a
      > release earlier than expected, there will only be less in.
      > I can imagine however that you'd like to track some minimal feature
      > list and that if these are not in the backlog you don't want to trim
      > the list further but extend the project's duration.
      > Are these arguments valid or am I missing something? More aguments
      > against the MoSCoW prioritization I can use?
    Your message has been successfully submitted and would be delivered to recipients shortly.