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

RE: [scrumdevelopment] Re: priority of backlog items

Expand Messages
  • Jeff
    Seriously, I do use a bit of scrum, and some of the decision facilitation skills with the family occasionally. Like, when we re trying to figure out what to
    Message 1 of 32 , Mar 1, 2006
      Seriously, I do use a bit of scrum, and some of the "decision facilitation  skills" with the family occasionally.
       
      Like, when we're trying to figure out what to do for the weekend, etc.
       
      Sounds wacky, but it works; the result is there's less angst.  Gives new meaning to the old "family meeting time" thing.
       
      B^)


      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Dagan, Tiran
      Sent: Wednesday, March 01, 2006 6:22 AM
      To: scrumdevelopment@yahoogroups.com
      Subject: RE: [scrumdevelopment] Re: priority of backlog items

      Mike,
       
      I love your example. I will be getting married in April. Developing the marriage in 30 day sprints sounds like a solid plan. In anticipation of the "release planning" (bachelor party), I have identified the stakeholders (parents and all those joining us for a free meal at our wedding). The problem is that my team (of one) is also the product owner. This may become pretty dicey.  
       
      :-)
       
      Tiran.

      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Mike Cohn
      Sent: Friday, February 24, 2006 3:18 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: Re: [scrumdevelopment] Re: priority of backlog items

      During sprint planning the team makes a /commitment/ to completing the development of the product backlog items they pull into the sprint.  If you are committed to something you do not need to prioritize within that commitment. When I got married I committed to love, honor and cherish my wife. I didn't prioritize those and tell her that one may drop out of the list if I run out of time. If the team cannot commit to all the product backlog items they should have the courage to drop the item from the sprint rather than prioritize it and then not do it. 

      Regards,
      Mike Cohn
      Author:
        Agile Estimating and Planning
        User Stories Applied
      www.mountaingoatsoftware.com


      On Feb 24, 2006, at 1:06 PM, Steven Gordon wrote:

      I was speaking ideally.
       
      The steps it takes to get there will of course vary quite a bit depending on culture, skills, product complexity, etc.
       


       
      On 2/24/06, Deb <deborah@...> wrote:
      > that they either do not know how to use these OO techniques or just
      not using them.

      Yes, exactly. My approach has been to implement Scrum first, and then
      XP, design patterns etc practics as the team sees that they solve
      problems they are encountering. However, I do see your point

      > To do this [develop in PO priority order], developers have to
      > learn to write loosely couple code.

      This does make sense, if a team has the internal leadership to do it.
      As you say, we can't command them to do this :-)

      deb

      --- In scrumdevelopment@yahoogroups.com , "Steven Gordon"
      <sgordonphd@...> wrote:
      >
      > What I am saying is that if developers have to implement a story which
      > seeming depends on other stories having to be already implemented, OO
      > techniques allow us to do this even if the dependent stories have
      not been
      > implemented yet.  Briefly, you make the dependencies explicit via
      one of a
      > few standard design patterns and "mock" the ones that are not yet
      > implemented.  Doing this has the benefit of making functionality
      > independently testable, independently demonstrable and loosely
      coupled from
      > its dependencies.  The functionality is not independently usable in
      > production, but that is a release-level issue, not a sprint-level issue.
      >
      > If developers are insisting they cannot (or that it takes too much
      time to)
      > implement something until certain other things have been first
      implemented,
      > it means that they either do not know how to use these OO techniques
      or just
      > not using them.  Either way, if the developers are not using these
      > techniques to make dependencies explicit and mock them to do
      functionally
      > independent impementation and testing of units of code, then the
      system they
      > are building will not be loosely coupled.  This leads to software
      that is
      > difficult and expensive to maintain or change.
      >
      > I would prefer not to use command and control tactics to impose these
      > techniques on developers.  A far less onerous way to motivate the use of
      > these techniques is to just say:
      >
      > The developers own the estimates; the product owner owns the priorities.
      > The product owner will not schedule more stories for a sprint than the
      > developers can commit to.  The developers will complete the stories
      in the
      > order determined by the product owner's priorities so that if any
      stories do
      > not get finished, they are the lowest priority stories.
      >
      > To do this, developers have to learn to write loosely couple code.
      >
      > There is one obvious exception:  The developers have 1 day and two
      stories
      > left - a small lower-priority story and a higher priority story that
      cannot
      > be completed in the remaining time.
      >
      > =========================================================
      >
      > I am under the impression that the goal of a sprint is working
      software that
      > implements a specific negotiated, prioritized set of business
      > functionalities, not some higher level goal for which the specific
      business
      > functionalities are just evolving details.  On the other hand, the
      goal of a
      > releases is implementation of a higher level business functionality, the
      > scope of which does indeed evolve.
      >
      > Steven Gordon
      >
      > On 2/24/06, Jeff Heinen <jheinen@...> wrote:
      > >
      > > Interesting, although I'm not sure I see how working on things
      strictly
      > > according to the Product Owner's priorities within a sprint
      meaningfully
      > > reduces dependencies and coupling.
      > >
      > > I see the discussions with the product owner around story
      scheduling or
      > > dissaggregation (and to be clear, I absolutely expect that the
      team should
      > > do this with the PO) as somewhat orthogonal to the question of how
      the goals
      > > get achieved within the sprint. If the objective is working,
      tested code, I
      > > as the product owner don't really care how the team goes about
      meeting that
      > > objective. What I do care about is the goals, and if the team
      believes it
      > > can't meet them it is incumbent on the team to renegotiate the
      goals with
      > > me.
      > >
      > > -Jeff H.
      > >
      > >
      > >
      > >  ------------------------------
      > > *From:* scrumdevelopment@yahoogroups.com [mailto:
      > > scrumdevelopment@yahoogroups.com] *On Behalf Of *Steven Gordon
      > > *Sent:* Friday, February 24, 2006 10:43 AM
      > > *To:* scrumdevelopment@yahoogroups.com
      > > *Subject:* Re: [scrumdevelopment] Re: priority of backlog items
      > >
      > >
      > >  Looks like another subtle difference between Scrum and XP.
      > >
      > > It is just too easy to let the developers use excuses about
      dependencies
      > > and unshared skills to put their convenience ahead of the
      customers'.  Being
      > > forced to work around those issues results in software with less
      > > dependencies and less places that only one person knows how to
      maintain or
      > > advance.  In other words, the software will tend to be more
      loosely coupled
      > > and less difficult to maintain and change if we do not allow the
      developers
      > > to change priorities for their convenience.
      > >
      > > Why is it not more constructive for the developers to simply
      explain their
      > > problem and ask the product owner to not schedule a problematic
      story for
      > > this sprint or to break the story so that the part that is not
      problematic
      > > can be done this sprint?  To let the product owner think her
      priorities will
      > > be honored and then trump her priorities during the sprint
      unnessarily risks
      > > a slow erosion of relationships, roles and trusts.
      > >
      > > (Outside of software, where dependencies actually do impact whether
      > > something can be built or not, the development team may well
      require more
      > > latitude).
      > >
      > > Steven Gordon
      > >
      > > On 2/24/06, Jeff Heinen <jheinen@...> wrote:
      > > >
      > > > I have to agree with Deb. *Within a sprint* the team decides
      what they
      > > > work on and when. As I understand it, the scrum 'contract' is
      that the
      > > > Product Owner gets to set the priority of the items to be worked
      on from
      > > > sprint to sprint, but once the sprint has begun the team has
      free reign to
      > > > achieve the goals of the sprint *by any means necessary*, free
      from any
      > > > interference from the Product Owner. It is perfectly acceptable
      for the team
      > > > to determine that the lowest priority backlog item committed to
      in the
      > > > sprint is the first thing that is worked on if they decide that
      doing so
      > > > would result in acheiving the rest of the goals more
      efficiently. The main
      > > > point is that within the sprint, the team is compeltely and utterly
      > > > responsible for determining how they meet the spring goals. The
      only thing
      > > > that counts is producing potentially shippable increments of
      code by the end
      > > > of the sprint.
      > > >
      > > > In our case (where we have been having issues with items being 90%
      > > > complete) I have tried encouraging the team to focus on
      completing an item
      > > > before moving on to the next, but that has proven to be difficult in
      > > > practice since very often there are backlog items that simply
      don't require
      > > > the effort of the whole team, and the result would be having
      half the team
      > > > sitting around waiting while the other half completes the item.
      What has
      > > > seemed to work better is to be very clear about the acceptance
      criteria for
      > > > each backlog item, and then being absolutely draconian about
      meeting the
      > > > criteria. If it doesn't meet the criteria, it's not done and the
      team gets
      > > > no credit. Period. No half credit, no credit for effort; just
      focus on the
      > > > goals.
      > > >
      > > > -Jeff H.
      > > >
      > > >
      > > >
      > > >  ------------------------------
      > > > *From:* scrumdevelopment@yahoogroups.com
      [mailto: scrumdevelopment@yahoogroups.com]
      > > > *On Behalf Of *Steven Gordon
      > > > *Sent:* Friday, February 24, 2006 7:28 AM
      > > > *To:* scrumdevelopment@yahoogroups.com
      > > > *Subject:* Re: [scrumdevelopment] Re: priority of backlog items
      > > >
      > > >
      > > >  I do agree that the teams should attach stories in priority
      order.  Not
      > > > only to make sure any unstarted or unfinished story is the
      lowest priority,
      > > > but also to make sure that no more than one story is partially
      complete at
      > > > the end.
      > > >
      > > > However, I disagree that a team should ever replace the customer's
      > > > priorities with their own.  It is the customer's project. If the
      developers
      > > > feel the priorities should change, they should convince the
      product owner
      > > > rather than just go ahead and change them.
      > > >
      > > > If the reasons are due to team preferences or constraints,
      overcome them
      > > > (and/or take those constraints into account on the estimates).
      If the
      > > > reasons are due to external constraints, the owners of those
      constrains can
      > > > usually be considered other customers of the project.  The
      product owner
      > > > should be made aware of these other customers and own the job of
      weighing
      > > > the tradeoffs among all the customers in order to speak with a
      single
      > > > voice.  Overriding the product owner undermines the product
      owner's role and
      > > > responsibility.
      > > >
      > > > Steven Gordon
      > > >
      > > >
      > > > On 2/24/06, Deb <deborah@...> wrote:
      > > > >
      > > > > Hi Boris.
      > > > >
      > > > > I encourage teams to attack stories in priority order, so that
      at the
      > > > > end of the sprint, any removed or not-started (gasp!) work is of
      > > > > lowest relative priority. As the team gets better at
      estimating this
      > > > > is less likely and so (perhaps) less urgent.
      > > > >
      > > > > However: Sprint priority may be different from the original
      Product
      > > > > Backlog priority, and is set by the team based on what they
      know about
      > > > >
      > > > > the work (which includes team interdependencies or technical
      > > > > priorities the customer may not be aware of).
      > > > >
      > > > > The team should set these priorities in conjunction with
      confirming
      > > > > the customer's Sprint Goal at the end of planning. Although
      the team
      > > > > sets the priorities inside the Sprint, it's good to include the
      > > > > customer in the conversation to forstall mistaken assumptions
      on the
      > > > > part of the team.
      > > > >
      > > > > Make sense?
      > > > > deb
      > > > >
      > > > >
      > > > > --- In scrumdevelopment@yahoogroups.com, Boris Gloger <boris@>
      > > > > wrote:
      > > > > >
      > > > > > Hi --,
      > > > > >
      > > > > > I would like to get a feeling about the way teams work on their
      > > > > > backlog items.
      > > > > > Maybe you  out in the field could give us some ideas.
      > > > > >
      > > > > > Do you try to keep the whole team engaged on one backlog
      item one
      > > > > > after another? So do you keep the proritization of the Selected
      > > > > > Product Backlog?
      > > > > >
      > > > > > Or do you hope that at the end of the sprint everything is
      finished?
      > > > >
      > > > > >
      > > > > > @Jeff - this is by the way the solution for the problem to
      have all
      > > > > > the time only 95% of each item "done".
      > > > > >
      > > > > > Boris
      > > > > >
      > > > > >
      > > > > > Boris Gloger
      > > > > > boris@
      > > > > > www.sprint-it.de
      > > > > > www.scrumeducation.com
      > > > > >

    • 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, 2006
        > 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.