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:
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
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.
for an in depth detailed explanation see: How to Meet a Project Deadline with Scrum In 7 simple steps For the Business, Agile Project Manager, Scrum Master, Product Owner, and Development Team
for a COMPLETE OVERVIEW OF SCRUM see this cost effective MEGA EBOOK: Scrum, (Mega Pack), For the Agile Scrum Master, Product Owner, Stakeholder and Development Team