Keeping Buffer in Sprint Planning
From few questions on the forum, I noticed that keeping the buffer in sprint planning is not a good practice.
Question -
How to manage the work if we don't keep the buffer in 2 week sprint and resource goes on unplanned (sick) leave?
Because other team members are already allocated and working on the task based on their capacity.
Any idea, how to deal with this situation?
How to manage the work if we don't keep the buffer in 2 week sprint and resource goes on unplanned (sick) leave?
Because other team members are already allocated and working on the task based on their capacity.
How is implementation of Scrum going to deliver maximum value, when people are assigned to specific tasks instead of the team trying to collectively deliver the maximum valued work?
the answer to your opening question can be found in my question ;)
Because other team members are already allocated and working on the task based on their capacity.
That doesn't sound very collaborative or accommodating of emergent change. Shouldn't the team be focused on achieving the Sprint Goal, and replanning their work as needed?
How to manage the work if we don't keep the buffer in 2 week sprint and resource goes on unplanned (sick) leave?
Don't you think there are anyways some level of uncertainties involved while developing a product ? How does your team act on them when they arise ? How much buffer you think can manage them ?
My point is rather a buffer , may be think about how the team should act together whenever unforeseen situations like this arises. One of the Agile manifesto is - 'Respond to Change'.
completing the above statement -
One of the Agile manifesto is - 'Respond to Change' over following a plan
How to manage the work if we don't keep the buffer in 2 week sprint and resource goes on unplanned (sick) leave?
How do you execute your Daily Scrum Is it a status meeting, or is it an inspect an adapt event for the team?
Quit looking at sprints as if they are mini-waterfall project plans. In Scrum, the Sprint Backlog can change daily (and is owned by the Development Team) based on what is learned and progress made (or not made), as long as the Sprint Goal remains viable.