Re: Benefit vs. Penalty on a product backlog
- --- In firstname.lastname@example.org, David A Barrett
> >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
> Scrum projects go, so you should get used to it. Why? Because veryoften,
> the longer that you wait the more variables and unknowns are removedfrom
> the equation. As time passes, people learn things, they get morefamiliar
> with how the product looks, feels and works and the programmerslearn more
> about how the PO wants the product to take shape. Why buildsomething you
> don't need yet, when waiting will increase the chances that you'll do apenality
> 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
> of not implementing the change which is the problem, but the possibilitychange in
> that the PO will wait too late for you to be able to complete the
> time. That's what you need to address.to work
> When there is a "drop dead" deadline for a feature, I find it best
> backwards from that deadline to determine the number of Sprints that areway we
> going to be required to get the feature full built and tested. The
> work around here, on one month Sprints, is to basically allocate no morecommitment
> 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
> and hits the threshold that we've found for how much newfunctionality that
> the users can absorb, test and understand in one bite."Binary Order
> We estimate on what I call the "BOOM" scale, which stands for
> 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 Backlogwithout
> being carved up into several smaller items (of which only some will makeenough for
> the Sprint Backlog, usually). These estimates have proven good
> practically all of the planning we need.classified as
> So if I'm faced with a hard dealine and the work involved is
> large or huge, I'd start l breaking it down into smaller tasks andgetting
> a real handle on how much work it will take. Getting time from variousneed to
> business units can be tricky at some times of the year too, so I'll
> take that into account or make special arrangements with the usersto get
> the resources freed up in advance. At that point I know pretty muchwhat
> Sprint I'd need to get the work started in order to be able tocomplete it
> on time.negotiable
> The key here is that the estimates and timelines involved aren't
> (unless, as usual the PO wishes to reduce the scope, in which case we'llthis at
> work up new estimates), so when you tell the PO, "You need to put
> the top of the list now, or we won't be done in time", that's the end ofpriority.
> 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
>I agree - the key to this is making the PO aware that failure due to
> Dave Barrett,
> Lawyers' Professional Indemnity Company
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....