When a team commits to delivering a number of features in a specific time period, it is common knowledge that they do not know at that point what kind of impediments they will have to contend with. Common impediments to delivery are:
1. Absenteeism
2. Failure of software or hardware resources
3. People pinching (team members moved to other teams)
4. Unforeseen defects with the product
5. Necessary (and unnecessary) meetings
(NOTE: Struggling to understand the basics of scrum quickly? Get the Power of Scrum Audio Book. You can use it to get a complete overview and foundation in scrum fast, before even having to “roll-out” a single scrum practice to your team. Check it out here.)
Due to a combination of these factors, a forecast of one day’s effort for a task can actually take multiple days. For this reason, it makes sense to buffer all tasks with some contingency based on the expert’s knowledge (see my chapter on using evidence from the past). The key thing here is to buffer in as many places as possible. In my teams I suggest adding buffers in the following areas:
1. A cut off date within the sprint by which development must finish to make sure that Quality Assurance (QA) have time to finish their work.
2. Features (usually estimated in story points) are estimated higher where there is uncertainty
3. Task estimates (usually estimated in hours, up to no more than a day) are usually increased to allow for known impediments
4. The number of days in the sprint are usually modified to reflect planning, a known consistent amount of time for meetings and recurring impediments. E.g. a 2 week sprint could become actually 8 days based on the above.
I recommend that you apply the principles above and adjust the times until you achieve a level of consistent delivery.
(NOTE: Struggling to understand the basics of scrum quickly? Get the Power of Scrum Audio Book. You can use it to get a complete overview and foundation in scrum fast, before even having to “roll-out” a single scrum practice to your team. Check it out here.)
