Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
Why not just adjust your available hours during sprint planning and also only plan for x hours a day that would allow for flux from people missing an unplanned day. Say like 75%-80% of their full capacity? Helps account for sick days, emergencies, and meetings. – Rig Feb 18 '14 at 17:07
@Rig: Then what do you do next sprint, when you hit 90%? Do you assume that you miscalculated? Do you assume they're not as productive as you thought? Or do you assume that you got it right and set a higher velocity next sprint? -- Not saying I have the answer (the same problem comes from assigning a PBI), but people are trying to make it sound simpler than it is. – pdr Feb 18 '14 at 18:01
At the end of the sprint you should be looking at the 'why' as to why you were over. Use it as a learning experience for the next sprint. During sprint planning is your team independently stating how many hours each will have available? Its why its (sort of) common to do a retrospective for a sprint to see what went well, what could be done better, and where the bottlenecks were. – Rig Feb 18 '14 at 18:11
up vote 13 down vote accepted


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.

share|improve this answer
We count how many man-days we will have in the sprint in SP1 and let that have an influence on how much we pull (might be off like 50% or even more in main vacation time in summer). This can and will be recorded and used to adjust velocity. – Flo Feb 18 '14 at 21:16

I don't think it is a good idea.

Such a story would deliver no business value to the Product Owner. It's just a hack to get your burndown chart to work.

We don't like hacks :)

Why not simply adjust your burndown chart's projected completion date by adjusting the expected velocity?

share|improve this answer
It was actually suggested by the Product Owner! I guess from his point of view the value would be in not thinking there was a problem with the sprint when it was just someone on vacation. – ndyer Feb 18 '14 at 16:55
Sprint health is more a concern of the Scrum Master and the implementation team than that of the Product Owner. Value for the PO role is usually measured in functionality delivered. That said, your PO was probably just trying to help out. It just happens that his Scrum advice wasn't the best. Not the end of the world. – MetaFight Feb 18 '14 at 17:44

Your burndown chart is there to help the team, including the product owner, determine if you are on track or not to making your commitments for the sprint. You should do whatever it takes to make it useful for that purpose. If you can look at it and quickly explain away any deviations, and still be able to tell if you're on track, then there's no need for things like vacation stories.

On the other hand, I've had stretches where because of the way we used the tool, the burndown chart was made completely useless, so people stopped looking at it and caring about it. If that's your situation frequently, then something like a vacation story can be very useful.

I would personally prefer if the tool could change the ideal line to be something other than a linear progression, but since most can't, then using a story to adjust the burndown to give a linear progression is certainly okay, as long as it preserves the chart as a faithful representation of your actual progress. If you're manipulating it to make your burndown look pretty even when the people still in the office aren't making real progress, then you're doing it wrong.

Note that you want such a story to affect only your burndown, not your velocity, for the reasons other answers have pointed out. That means I wouldn't assign story points to a vacation story, just hours.

share|improve this answer

It's not a standard approach, no.

But your team is having a problem with tracking / recording / identifying hours since the Product Owner has requested making a change. So it may make sense in your case.

Generally, team members bid for projects based upon the number of points they believe they'll have within that sprint. That means each team member needs to be aware of any commitments that would keep them from taking a full sprint's worth of points.

You may also need to consider other "blanket" story types for ad-hoc meetings, customer support, administrivia, etc... if the Product Owner doesn't feel like they are seeing all of the time that should be reflected within a sprint.

share|improve this answer

This its like cheating to yourself; it's a very bad idea.

A burndown shows your real progress, and obviously someone's vacation is not progress on your product.

If your PO insists, I have one proposition: All user histories are people vacations! The people are happy and the burndown its happy too! And never, never is there a deviation in your precious burndown charts! (its a joke)

share|improve this answer

Assuming that the vacation is planned, then you just adjust the amount of time allocated for the developer accordingly. In that case the burn down may not be as good in the beginning, but should catch up properly in the end.

However, if it isn't planned, you can add it as an Sprint Impediment. Which needs to be noted. In which case if some unplanned things occur you may discuss it on the retrospective to perhaps adjust the standard allocation or just ignore it (which is valid) because it may have been a one off incident.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.