We have had a situation with a scrum sprint where a team member went on vacation for a few days at the beginning of the sprint. This led to us being behind the ideal trend on the burndown chart at the beginning of the sprint, although we caught up later since we knew we had slightly less resource and as a result had committed to deliver slightly less.In our retrospective it was suggested by the Product Owner that we create a vacation story. The time remaining would be reduced down as the vacation was completed. As a result the burndown chart would be corrected for the hole that would appear in effort when the team resource was lower, which would otherwise falsely indicate a problem.Is this a good idea?
Should we create a story for vacation?
agile;scrum;sprint
No.First off, vacation isn't a problem, it's a reality. The burn-down chart is supposed to reflect the reality of the project's progress, and if the project progressed less during one sprint compared to another due to vacation, a proper sprint burn-down chart will reflect that.Secondly, vacation (along with other administrative functions) is expected to happen over the course of a project. The impact that such interruptions have on the project's average sprint velocity will even out over time. The resulting average velocity will be a more realistic indicator of available development effort per sprint than some calculation like #OfDevelopers * SomeStandard#OfHours per Sprint. If you corrupt your sprint velocity by adding stories that aren't really stories, you'll never get this realistic view of your project's progress.