Should we create a story for vacation?

Question

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?

Answer 1

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.

Answer 2

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?

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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)

Answer 7

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?