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

Re: Benefit vs. Penalty on a product backlog

Expand Messages
  • barvybe
    ... that most ... often, ... from ... familiar ... learn more ... something you ... penality ... change in ... to work ... way we ... commitment ...
    Message 1 of 14 , Apr 28, 2007
    • 0 Attachment
      --- In scrumdevelopment@yahoogroups.com, David A Barrett
      <dave.barrett@...> wrote:
      >
      >
      > >I think, perhaps, it comes down to how I am able to communicate the
      > >risk associated with ignoring the change. Ultimately the Product
      > >Owner has the good of the software in mind, I think, but they are
      > >playing a little bit of a game of chicken with some of these items -
      > >ignoring them in favor of other requests up until the last moment.
      > >That is their call, but I would like to be in the position of not
      > >waiting on every required change up until the cusp of system failure.
      >
      > This changes things slightly.
      >
      > I see no problem with "ignoring them in favor of other requests up until
      > the last moment". That's the best way to do things, and the way
      that most
      > Scrum projects go, so you should get used to it. Why? Because very
      often,
      > the longer that you wait the more variables and unknowns are removed
      from
      > the equation. As time passes, people learn things, they get more
      familiar
      > with how the product looks, feels and works and the programmers
      learn more
      > about how the PO wants the product to take shape. Why build
      something you
      > don't need yet, when waiting will increase the chances that you'll do a
      > good job of building it better?
      >
      > "The cusp of system failure", sounds a little worrying, I have to admit.
      > What I think you're focusing on is wrong, however. It's not the
      penality
      > of not implementing the change which is the problem, but the possibility
      > that the PO will wait too late for you to be able to complete the
      change in
      > time. That's what you need to address.
      >
      > When there is a "drop dead" deadline for a feature, I find it best
      to work
      > backwards from that deadline to determine the number of Sprints that are
      > going to be required to get the feature full built and tested. The
      way we
      > work around here, on one month Sprints, is to basically allocate no more
      > than 5 man days on any given PB item in a single Sprint. That will
      > translate to about 1/2 of the Sprint for a single programmer which, with
      > the way the do work for several departments, is a big manpower
      commitment
      > and hits the threshold that we've found for how much new
      functionality that
      > the users can absorb, test and understand in one bite.
      >
      > We estimate on what I call the "BOOM" scale, which stands for
      "Binary Order
      > of Magnitude". Estimates are tiny, small, medium, large and huge.
      These
      > correspond to 1/2, 1, 2-3, 4-5, and 6+ days, roughly. The "huge"
      estimate
      > exists only for PB items, and they never make to a Sprint Backlog
      without
      > being carved up into several smaller items (of which only some will make
      > the Sprint Backlog, usually). These estimates have proven good
      enough for
      > practically all of the planning we need.
      >
      > So if I'm faced with a hard dealine and the work involved is
      classified as
      > large or huge, I'd start l breaking it down into smaller tasks and
      getting
      > a real handle on how much work it will take. Getting time from various
      > business units can be tricky at some times of the year too, so I'll
      need to
      > take that into account or make special arrangements with the users
      to get
      > the resources freed up in advance. At that point I know pretty much
      what
      > Sprint I'd need to get the work started in order to be able to
      complete it
      > on time.
      >
      > The key here is that the estimates and timelines involved aren't
      negotiable
      > (unless, as usual the PO wishes to reduce the scope, in which case we'll
      > work up new estimates), so when you tell the PO, "You need to put
      this at
      > the top of the list now, or we won't be done in time", that's the end of
      > that. You tell the PO how long it takes, and he tells you when he wants
      > you to start on it.
      >
      > If you have concerns about the possibility of something going wrong, and
      > the estimates turning out to small, you need to make sure that the PO
      > understands how big you consider that risk. After that, it's his
      > responsibility as the "Product Owner" to give it an appropriate
      priority.
      >
      > Dave Barrett,
      > Lawyers' Professional Indemnity Company
      >
      I agree - the key to this is making the PO aware that failure due to
      not implementing this is his responsibility since the prioritization
      is his. So long as it is 100% clear to the PO that in order to avoid
      an issue, this item needs to be started X time units before a specific
      date the PO should now own the problem....

      - Pete
    Your message has been successfully submitted and would be delivered to recipients shortly.