Re: [scrumdevelopment] Scheduling buffers
- I think I see where the disconnect in that other thread is coming from.
As far as I'm concerned, the effort estimation of PBIs serves three purposes:
1) Help the Product Owner prioritize, considering ROI
2) Help the Product Owner readjust release planning expectations
3) (the one I've noticed more and more with the Planning Poker
approach) cause the PO and team to have discussions about the scope of
the items, revising them if possible.
The team may also use them as guidelines of what to commit to in one
Sprint, but that's up to them.
On 4/24/09, Michael James <michael@...> wrote:
> This reminds me I promised to write more about this.
> Where are people getting the idea Scrum dev teams are responsible for
> "schedule"? Managing scope to hit a release date is largely the
> Product Owner's job. Teams commit a negotiated amount of work (PBIs)
> from one Sprint to the next. I suppose they can "schedule" tasks
> within the Sprint if they want.
> On 4/24/09, Eric Deslauriers <eric.deslauriers@...> wrote:
>> Hi Peter,
>> Some teams benefit from using PERT, especially if they struggle to
>> good estimates, if for no other reason than it makes them walk through
>> We start with "thumb-in-the-air" estimates, which we pin at 50% likely to
>> accurate for some projects. After going through the initial sessions, we
>> should be able to deliver estimates in the 90% range when we have strong
>> experience in the domain (for sure).
>> One way team members can do that is to define their "number". One of my
>> members knows his initial-estimates are very frequently appx 2/3 the size
>> the actuals. So he just takes his initial estimate, multiplies it by his
>> number (1.5), and ends up being pretty close much of the time. Personally,
>> don't get that - my estimates are usually right in the ballpark, but I
>> really explain how I do it (unconscious competence) and since this
>> works for a lot of folks, sounds like a good deal to me. :)
>> Re your buffer question -
>> - Some teams prefer optimistic schedules - set an attractive date, then
>> it out as needed. Seems to be a preference when doing consulting. I see
>> schedules sometimes that have no accommodation for resolving defects and
>> regression testing the subsequent builds (it's not all automated).
>> - Other teams prefer pessimistic schedules - deliver early.
>> - I prefer realistic schedules with a slight lean towards pessimism. It's
>> always better to deliver a little early than a little late. <grin> This
>> means that we estimate 1-2 more builds than we think it will take at the
>> outset, then reset expectations if our quality is different than what we
>> assumed when we started.
>> On Thu, Apr 16, 2009 at 11:46 PM, Peter Stevens (calendar) <
>> peterstev@...> wrote:
>>> Hi everyone,
>>> In Mike Cohn's Agile Planning and Estimating books, he writes about
>>> using 50% estimates (50/50 chance that the story will be finished in
>>> time <= estimate) and 90% estimates (90% that t <= e ). He goes further
>>> to calculate a project buffer, based on the square root of the sum of
>>> the squares of the differences between e(50) and e(90). (page 195 for
>>> someone want to look up the reference).
>>> Does anyone out there use these techniques to estimate the actual
>>> completion time of a project? What experience have you had with them?
>>> Thanks in advance,
>>> Peter Stevens, CSM, CSP
>>> tel: +41 44 586 6450
>> Eric D
>> 08 K1200S Tricolor (phreowww)
>> 06 Husqvarna TE610
>> Sandy Eggo, CA (Ramona)
> Sent from my mobile device
Sent from my mobile device