schedule buffers in scrum

[dotnetguy]

Hello - Scrum says you can use schedule buffers as long as you're
transparent in how you present them.  Do you have a standard set of
schedule buffer factors you use on projects as needed?  For example,
here's a set of schedule buffer factors I used on a previous project:

• Integration and iteration
• Revisions and unforeseen requirements
• Meetings and other supporting tasks
• Standard max resource allocation of 80% per developer
• Variable resource availability
• Planned and unplanned PTO
• Importance of completing on schedule

Using a set of schedule buffer factors like this gives you a lot of
lenience in applying the amount of buffer you feel is appropriate. For
example, standard max resource allocation of 80%/developer (standard
PM practice) gives you an automatic buffer of +20%. 1 day of planned
or unplanned PTO per team member gives you another automatic buffer of
+10%.

Importance of completing on schedule is a weighted factor.  If it's
not that important then you don't need to allocate much if any buffer
for this.  However, if this is critical then you might want to
allocate a buffer of up to 20% for risk management. Please let me
know if you have a standard set of schedule buffer factors that you
like to use as needed for Scrum projects....

[Dan Rawsthorne]

many of these are the sorts of thing I'd probably use PlaceHolder Stories for (chapter 4.4), and having a buffer of unallocated StoryPoints seems like a good idea to me...

Dan Rawsthorne, PhD, PMP, CST
3Back.com
Author of Exploring Scrum: the Fundamentals

On 7/20/2012 8:46 PM, dotnetguy wrote:

Hello - Scrum says you can use schedule buffers as long as you're
transparent in how you present them. �Do you have a standard set of
schedule buffer factors you use on projects as needed? �For example,
here's a set of schedule buffer factors I used on a previous project:

��Integration and iteration
� Revisions and unforeseen requirements
� Meetings and other supporting tasks
� Standard max resource allocation of 80% per developer
� Variable resource availability
� Planned and unplanned PTO
� Importance of completing on schedule

Using a set of schedule buffer factors like this gives you a lot of
lenience in applying the amount of buffer you feel is appropriate. For
example, standard max resource allocation of 80%/developer (standard
PM practice) gives you an automatic buffer of +20%. 1 day of planned
or unplanned PTO per team member gives you another automatic buffer of
+10%.

Importance of completing on schedule is a weighted factor. �If it's
not that important then you don't need to allocate much if any buffer
for this. �However, if this is critical then you might want to
allocate a buffer of up to 20% for risk management.  Please let me
know if you have a standard set of schedule buffer factors that you
like to use as needed for Scrum projects....

[RonJeffries]

Andrew,

On Jul 20, 2012, at 11:46 PM, dotnetguy wrote:

Hello - Scrum says you can use schedule buffers as long as you're
transparent in how you present them.  Do you have a standard set of
schedule buffer factors you use on projects as needed?  For example,
here's a set of schedule buffer factors I used on a previous project:

Schedule buffers are a weak approach to doing a project and actually interfere with doing a project in a Scrum / Agile style.

The very idea connotes fixed content / fixed time thinking, and the buffers are a politically correct way of saying what is true, which is that we have no bloody idea how long the thing will take.

In Scrum, the Product Owner is responsible for getting the best possible product by the delivery date. The PO has only one way to do this: she decides what should be done next. She has in mind a broad product with some number of general capabilities, and many possible features. With whatever help she needs from the team, she slices the stories for maximum value and creates a minimum viable product as early as possible. She layers in things of lower importance, maintaining the best possible product at every moment, ensuring thereby that she has the best possible product by the end date.

Schedule buffers, estimation, all that stuff are looking at the cost side of the equation. There is no shelter there. We do Agile well when we manage value flow, not when we try to go faster than we can reasonably go, and certainly not by putting slack into our schedule.  We do need some sense of schedule, of course, but our mission is to manage value flow, not cost flow.

Ron Jeffries

www.XProgramming.com

 Before you contradict an old man, my fair friend, you should endeavor to understand him. - George Santayana

[dotnetguy]

@Ron - most processes have some amount of variation. Common causes for
this variation are usual, historical, quantifiable variations. As a
SM you might observe that although team members don't request PTO
before sprint planning, team members end up taking off an average of 1
day each before the end of the Sprint for planned and unplanned PTO.
If you don't account for variations like this up front then you're not
being realistic about a team's throughput capacity.  Adding a buffer
item for "planned and unplanned PTO" is simply identifying a common
cause variation of the process that needs to be recognized and
understood. An additional advantage is that these buffer items can
also be used as problem statements for DMAIC....

[RonJeffries]

On Jul 23, 2012, at 7:01 PM, dotnetguy wrote:

@Ron - most processes have some amount of variation. Common causes for
this variation are usual, historical, quantifiable variations.  As a
SM you might observe that although team members don't request PTO
before sprint planning, team members end up taking off an average of 1
day each before the end of the Sprint for planned and unplanned PTO.
If you don't account for variations like this up front then you're not
being realistic about a team's throughput capacity.  Adding a buffer
item for "planned and unplanned PTO" is simply identifying a common
cause variation of the process that needs to be recognized and
understood.  An additional advantage is that these buffer items can
also be used as problem statements for DMAIC....

Well, sure, you can do that. Or you can have the team sign up for the amount of work they think can actually do. If they fall short, they can figure out why. The Retrospective is one way of doing that. Then they improve how much they sign up for.

Neither the PO nor the SM owns the schedule of work in Scrum. The PO doesn't get to say how much the team signs up for. The SM doesn't get to say. The team owns it. I'd let them do it.

Ron Jeffries

www.XProgramming.com

If not now, when? -- Rabbi Hillel

[dotnetguy]

Now that I think about it, a more Scrum-like approach could be to
display the common causes of variation on a flipchart during sprint
planning.  Then using commitment-based planning, the SM could ask the
team to scan the flipchart of common causes of variation before
deciding whether to commit to an additional story....

[RonJeffries]

Andrew,

On Jul 23, 2012, at 7:48 PM, dotnetguy wrote:

Now that I think about it, a more Scrum-like approach could be to
display the common causes of variation on a flipchart during sprint
planning.  Then using commitment-based planning, the SM could ask the
team to scan the flipchart of common causes of variation before
deciding whether to commit to an additional story....

Let go of the reins. The horse knows the way home.

Ron Jeffries

www.XProgramming.com

I'm really pissed off by what people are passing off as "agile" these days.

You may have a red car, but that does not make it a Ferrari.

  -- Steve Hayes

[dotnetguy]

@Ron - I don't see an issue with this approach, especially if the
common causes of variation are identified by the team.  I remember I
was on a Scrum team one time that kept overestimating.  So the SM had
the team explicitly step through each part of DoD for each story
before committing.  It was an effective exercise because team members
weren't considering how long each part of done would actually take for
each story.

I could see a similar approach being used for common causes of
variation as an additional checkpoint to help ensure that the team is
being realistic about their throughput capacity....

[dotnetguy]

@Ron - I'd like to get your feedback on my last post.  It addresses 2
key challenges in Scrum:

* guiding the team without controlling the team
* approaches for delivery optimization

[Tom Mellor]

I don't know of any place where someone says that Scrum says you can
use schedule buffers. That smells a lot like critical chain project
methodology. I also don't know why the matter of guiding versus
contolling is of any interest. There is no formal guiding,
controlling, or directing of anyone in Scrum. Leadership emerges in
Scrum and I have observed the effectiveness of this over many years
and projects. It certainly trumps the traditional role of the project
manager. The team will think through how to best optimize delivery.
The team being the Product Owner, the ScrumMaster and the Development
Team. It won't likely do this exceptionally well at the beginning, but
it will almost surely improve on it over time.

We accept that there will be common causes of variation in the work,
our systems, and our delivery. Common caused variation is
statistically predictable, cannot typically be eliminated, and is a
cause of static or noise in the work environment. The organization
and its management (if it has management, otherwise everyone) must be
focused on resolving special causes of variation and that is the focus
of the ScrumMaster when it comes to removing impediments. We can find
that these special causes are particularly onery and may be difficult
to remove. That is a challenge that can be tackled or ignored.

Ron has good advice about letting go of the reins.

[RonJeffries]

Hi Andrew,

On Jul 23, 2012, at 7:48 PM, dotnetguy wrote:

Now that I think about it, a more Scrum-like approach could be to
display the common causes of variation on a flipchart during sprint
planning.  Then using commitment-based planning, the SM could ask the
team to scan the flipchart of common causes of variation before
deciding whether to commit to an additional story....

Yes, more Scrum-like IMO. Did I mention that the SM is not the moderator of all meetings? But she could still say things if she wanted to.

Another even more Scrum-like thing to do would be to make sure "didn't meet expected work volume" was brought up in the retrospective and let the team figure out how to do it. They really do very likely know more than the ScrumMaster, since there are a lot of them, and they certainly know better than the ScrumMaster how they think.

Ron Jeffries

www.XProgramming.com

If another does not intend offense, it is wrong for me to seek it;

if another does indeed intend offense, it is foolish for me to permit it.

  -- Kelly Easterley

[RonJeffries]

Hi Andrew,

On Jul 23, 2012, at 8:52 PM, dotnetguy wrote:

@Ron - I'd like to get your feedback on my last post.  It addresses 2
key challenges in Scrum:

* guiding the team without controlling the team
* approaches for delivery optimization

I believe I have now replied. Are you sure the ScrumMaster is supposed to "guide" the team?

As for "approaches for delivery optimization", in addition to the phrase being more than a little buzzword compliant, I would be concerned that it displays an excessive focus on the cost side of the equation. The value side has more leverage.

Ron Jeffries

www.XProgramming.com

There's no word for accountability in Finnish. 

Accountability is something that is left when responsibility has been subtracted. 

--Pasi Sahlberg

[Dan Rawsthorne]

I agree with Ron, and I'd like to go back to basics here...
 - The Scrum Team has two responsibilities:
   - to produce valuable, high-quality Results at a sustainable pace, and
   - to get better at doing that.
 - The PO's job is to guide the team by prioritizing the work to be done
 - The SM's job is to facilitate the Team's getting better
 - The Team's rate of production (Velocity) is a result of the Team doing its job
   - it is not a Goal, it is a byproduct
   - A Team gets more Velocity by getting better, not by wishing it would be faster
   - And it ain't real until it's real - Capacity assumptions are ALWAYS risky, yesterday's weather or not
 - Management makes planning assumptions about how fast the team will produce Results (Capacity)
   - sometimes these planning assumptions are wrong (Velocity does not equal assumed Capacity)
   - this is not the Team's problem as long as they are doing their job (see the above)
   - So something must change... there are four choices Management can choose from:
     - change in scope (what provides value) - a good choice
        - could reduce scope, and accept same Velocity but need less Capacity
        - could add "team improvement" items to scope, and hope to improve Velocity fast enough to "catch up" in spite of the added scope
     - changes in quality requirements (not recommended, obviously) - bad choice
     - work at unsustainable pace (work the team too hard) - bad choice
     - change the assumption itself - best choice
   - Since it is Management's assumption that is incorrect, Management makes the call about what changes, and then "owns" that decision
   - unfortunately, they often choose one of the bad choices, either on purpose or unwittingly, and then refuse to own it

Just sayin'...  Dan  ;-)

Dan Rawsthorne, PhD, PMP, CST
3Back.com
Author of Exploring Scrum: the Fundamentals

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To post to this group, send email to scruma...@googlegroups.com.
To unsubscribe from this group, send email to scrumallianc...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scrumalliance?hl=en.