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?

  • 5
    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
    Commented Feb 18, 2014 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
    Commented Feb 18, 2014 at 18:01
  • 2
  • 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
    Commented Feb 18, 2014 at 18:11

7 Answers 7



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.

  • 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
    Commented Feb 18, 2014 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?

  • 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
    Commented Feb 18, 2014 at 16:55
  • 1
    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
    Commented Feb 18, 2014 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.


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.


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.


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)


I'm late to the party, but it's important to give the counter argument to the purist answers.

Two big reasons for velocity and burndown charts are to improve predictability for the PM team and to give clear visual indicators during retros to help identify impediments.

You can make the case that accounting for those vacation points in this sprint will give you a more accurate three sprint rolling average when predicting capacity for next sprint (this vacation doesn't impact next sprint's velocity); helping a team plan more accurately.

In addition, if you can normalize the variance caused by controllable influences (like vacation) then it will be more obvious at a glimpse at the charts when real variation that may be due to real impediments and so should be discussed in retros arise.

On the other hand vacation isn't really output, so a purist would say that vacation actually does cost the team velocity and this should be reflected in the numbers.

So as a team, you can either treat vacation the way you would treat a timeboxed spike (like the questioner suggests), or you can do some extra math and accept some additional smoke in the charts when looking for trends. It's about tailoring the scrum framework to the current team & organizational needs.

Which way answers the question "how many points should we plan for in the next sprint" the best for your team?

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