The Agile Commons Blog
The top stories from the Agile Commons Community
blog entry
I have been thinking about and recommending the practice of Slack quite a bit recently. An attendee to one of my workshops just asked me to explain again why I asked him to reduce his committed capacity from 120% to 70%. He wondered why we wouldn't strive for 100%. I started to respond and then remembered a great post on the topic I wanted to reread.
From James Shore: http://jamesshore.com/Blog/Slack%20and%20Scheduling%20in%20XP.html
The most insightful statement he makes (at least for me) is: The more often you face these issues [customer unavailability, technical debt (including design debt)], the more unpredictable your environment is, and the more slack you need in order to meet your deadlines. In the case of technical debt, you can even use that slack to eliminate the problem!
I think that the amount of capacity you leave uncommitted is correlated to how much unexpected work and doubt you have going in to the iteration. Remember, we are trying to create visibility and become predictable. So we need to not over-commit. If you have interruptions, unexpected complexity and other challenges popping up in your iteration, then your estimates are going to be less accurate. When this is true, you need more slack in your capacity to allow you to deal with all of this uncertainty.
So, I didn't feel like I could give him an exact number, but I suggested trying an experiment.
- Try not committing to more than 70% for a couple iterations.
- See how it goes.
- If you consistently finish all of your work with little time to spare, that's the right number.
- If you consistently finish and need to take on more work, increase to 80% and test again.
- If you consistently keep ending the iteration with work still to do, decrease to 60% and test again.
Comments
Rachel,
Assume the team is committing to the sprint backlog based on their calculated velocity. Would you still advise to commit to 70 %?
My feeling says the velocity already includes the slack time...
For team commitments using velocity, I think the team should decide what measure to use for a maximum commitment level going into the iteration or release. Some teams use "yesterday's weather" - the velocity from the previous iteration as the maximum. I personally like an average over the last 3 or 5 iterations if you have it because I think it helps with some smoothing. If the team feels like there is a good reason for not trusting previous velocity and wants to commit to less, then they should agree to that and do it. They should also have a reason for doing it and some way to measure the impact of the reduced commitment so they can discover if their decision to go lower was actually useful.
This is different than the Slack we build into individual capacity and commitment. Here, the person is reporting on the time they actually have available to commit to tasks in this iteration. This varies much more than team velocity does from iteration to iteration as the impact to me of 5 days of vacation (woohoo!) is less than the impact to the whole team in terms of team commitment. It still matters of course, which is why I like the averaging of velocity mentioned above. But my personal availability, the tasks I am signing up for, the complexity, effort and doubt within each story and task, the amount of technical debt in the system, the potential for interrupt, and other unknowns will all weigh into how much Slack I might want to leave in my personal capacity.
If you are a cross-functional team that doesn't sign up for tasks in the iteration planning session and instead is able to pull tasks in as they/you are ready, then slack in individual capacity isn't as relevant. Instead, you might want to sum up the total hours each individual has available (e.g. 203 hours) and say, hey team, let's leave 20% slack (e.g. commit to only 162 hours).
I rambled a bit here - did I answer your question?
In Rally I have seen teams represent slack in a number of different ways. The simplest is to set your "resources" value for the Iteration to the velocity that your team would achieve if they did not have production issues, tech debt, unpredictable environments, etc. For example that velocity might be 22 points. The team would then only allow themselves to plan to around 70% of their velocity. This is clearly visible using Rally's Plan page. Other teams will add a user story for each of these potential disruptions in the iteration and estimate those stories so they consume the other 30% of the iteration and the team is showing that they are at 100% of capacity. Doing it this way allows you to later add tasks to the user stories and understand how much effort you are putting into production issues and other things in any given iteration. Over time it is possible to find trends and make adjustments to your process.
Although there are a number of ways to make this visible with a wall or a tool it is important to have a conversation and as a group collectively understand what slack is for your team, why you have it, and why it is important to make it visible.
Great post Rachel - thank you for starting the discussion.
Interesting post - I agree with the general approach - especially with shared teams as Technical Debt is always higher.
But there is also the concept of "stretch" - the idea that the team should always be looking to improve and stretch targets are a good way to indicate this.
Rachel/Craig - Is there room for both "slack" and "stretch" and how would you best illustrate these within Rally?
Great question David. In my experience I have seen very few teams using stretch goals. The reason is that stretch goals tend to lend teams to making inaccurate commitments (poor estimating). With Agile we typically want a team to be able to look us in the eye and say, "yes we can deliver these stories at the end of two weeks." If the team finishes early we empower them to choose what they would like to do with the extra day or so. Would you like to improve quality on the features you just delivered, work on some tech debt, refactor, take vacation? If they do decide to work on the next highest priority features we look at our release backlog and grab the next highest priority feature off the list. The next iteration we might ask the team to increase their estimated velocity because we finished a day early on the previous iteration. Teams also tend to shy away from stretch goals because it lends to a decrease in quality (i.e. teams move on to complete stretch goals rather than focusing more effort on the quality of their original commitment) and sustainable pace for the team.
I do not want to discourage stretch goals if you are finding value in using them. Please feel free to add your comments and let us know why they are important to Product Owners and teams.
In Rally we do not have a field value for stretch goal, although you could add a custom field if you would like to represent this number. I have also seen teams over plan (i.e. plan to 130% of their estimated velocity). However, I would rather see teams create a line in their release backlog called "stretch goal for next iteration" and identify anything above the line as being a stretch goal for the next iteration. This will keep teams focused on their current commitments but give them visibility into what is next if they finish a day early.
Craig - In my experience stretch goals have both given the team something to aim for and given the Product Owner the feeling that the team are doing everything to get the project finished on time etc etc. I agree with your point about committing - in terms of expectation it should be positioned with the Product Owner that "we will do all of the items scheduled for this iteration" and "we may be able to do some of the stretch goals". On an agile wall the associated stories can be easily grouped to show this - it would be good if Rally could provide this ability. Currently we do find teams overcommitting to around 120% and maybe if this was differentiated from the Red colour then it might indicate the difference between heavily overcommitting and stretch goals.
Having written all this, I realise we're well off-topic from "Slack" - in fact heading in the opposite direction!!! ;-)