6

After reading Tom DeMarco's Slack, I'm wondering how to factor slack into sprints.

For those who haven't read the book, TDM describes 'slack' as providing time for innovation and other good things.

Scrum leans towards eliminating slack and resisting change within the sprint. Allowing stories to be re-prioritised between sprints. I appreciate the purpose of a sprint, and am not trying to ask how to respond to change within them.

My initial thought about adding slack to sprints would be to plan a sprint with 8/9 days of work for a two week sprint. If you're conscious of this decision, can still calculate your velocity accurately? Based on story points completed in your 8/9 day window (vs 10).

Conversely, these are two competing ideas and don't belong together... ?

gnat's focus factor link is interesting.

Improve this question
3
  • 2
    Not really an answer but I would say that 8 mandays per 2 week sprint is not enough slack. I would realistically put it closer to 6 to 7.5 man days. Efficiency to 100% is a pipe dream. People need to go to the bathroom, attend meetings, grab some coffee or grab a smoke. Those all eat a LOT of time when you add it all up. You also should anticipate the occasional sick day as well.
    – maple_shaft ♦
    Feb 17, 2012 at 18:01
  • 3
    at Scrums I've been a member of (in two different companies), there was enough slack provided by setting appropriate focus factor. If memory serves reasonable values for it are considered to be in between 40 and 70 %
    – gnat
    Feb 17, 2012 at 18:39
  • 4
    "Being productive is not the same as being busy."
    – JeffO
    Feb 17, 2012 at 20:13

4 Answers 4

Reset to default
9

Scrum leans towards eliminating slack

Yes and No.

Scrum forces you to make an intelligent "time for innovation and other good things".

  1. "Other good things" are what retrospectives and daily stand ups are for.

  2. "innovation" is what technology spikes or spike solutions are for.

They don't go away. They aren't buried.

They become first-class, highly-valued parts of the process.

Being responsive to change -- with one small constraint -- is the whole point of an Agile method and scrum in particular.

The one small constraint (wait until the end of the sprint) doesn't require building in slack time or otherwise tinkering with scrum or the development team.

It's easy to be responsive (by waiting until the end of the sprint) without building in needless overheads.

Innovation is supported through spike solutions.

Other Good Things are supported through daily stand ups and retrospectives.

Improve this answer
1
  • I have updated my question, I think my description of the book detracts from what I'm asking.
    – Greg K
    Feb 20, 2012 at 11:28
3

As someone who spent almost ten years studying manpower requirements, I can tell you that no one in any profession should ever be planned at 100% for direct work. We used a figure of a little over 30 hours of direct work per week per person. You have to account for meetings, breaks, unavoidable delay (fire drills comes to mind as an example), non-direct tasks (things such as the developers being called to do a fix for someone else or filling out HR forms or moving your desk), and vacation, sick time, and other types of leave such as bereavement leave. The lack of consideration of this is one of the main reasons why most software projects miss the promised due dates (or make the date but with less functionality than orginally promised) whether using waterfall or Agile methods.

Improve this answer
7
  • 1
    Am I misreading it, or did you say that you estimated a 60 hour work week was less than 100% output?
    – Daenyth
    Feb 18, 2012 at 1:08
  • 1
    @Daenyth, No I mistyped. 60 hours out of a 2 week pay period or 30 hours in a week.
    – HLGEM
    Feb 20, 2012 at 14:17
  • That sounds much more reasonable!
    – Daenyth
    Feb 20, 2012 at 17:08
  • At the company I work for, the contracted hours per week is 37.5 (9 - 5.30pm), pretty standard. Planning around 30hr weeks is basically recognising one day a week of noise that occurs as part of the job. Sounds logical, I imagine this will be a hard sell to some management types.
    – Greg K
    Feb 21, 2012 at 15:38
  • This specific overhead is already taken into account with scrum. 1. Usually a sprint planning assumes 6 hours per day. 2. Any type of repeating overhead would automatically be compensated for in the velocity. So your last statement does not make any sense.
    – Kris Van Bael
    Sep 22, 2013 at 6:44
3

In Agile Estimating and Planning Mike Cohn talks about slacking in a round about way by describing the difference between "ideal time" and "elapsed time":

Ideal time is the amount of time that something takes when stripped of peripheral activities.

Elapsed time [...] is the amount of time that passes on a clock.

More examples of why ideal time does not equal elapsed time are:

  • Supporting the current release
  • Sick time
  • Meetings
  • ...Phone calls
  • ...Email [your friends]
  • ...Task switching

One piece of advice he gives is to estimate based on ideal time, per user story.

Improve this answer
2
  • I own this book, I need to finish reading it!
    – Greg K
    Feb 22, 2012 at 12:52
  • +1 for this, I was torn between awarding this as my accepted answer and S.Lott's
    – Greg K
    Feb 27, 2012 at 12:04
1

In SCRUM, it's generally referred to as velocity.

Velocity incorporates all the concepts you mentioned - focus factor, "slack", etc. Point is that you should not artificially tweak your estimates or block off days as "slack". You try to estimate as consistently as possible and at the end of each sprint, you modify the velocity based on what you accomplished.

Improve this answer
2
  • Good. Then you should also know that velocity incorporates all the concepts you mentioned - focus factor, "slack", etc. Point is that you should not artificially tweak your estimates or block off days as "slack". You try to estimate as consistently as possible and at the end of each sprint, you modify the velocity based on what you accomplished.
    – pap
    Feb 21, 2012 at 15:35
  • 2
    That's even better, you should include it in your answer :)
    – Greg K
    Feb 21, 2012 at 15:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.