Estimating Placeholder Stories is a Bad Practice

Placeholder stories, in general, are a bad idea. Estimating placeholder stories to reserve capacity or to get credit is a very bad idea.

Define “Placeholder Stories”

Of course, all stories are “placeholders for a conversation”, but that’s not what I’m talking about here.

I am also not talking about things like “Refactor the such-n-such class as we start work on the something-or-another Epic”. I’m not talking about having a known customer problem but not yet knowing what to do about it, if anything. Those are specifically identifiable work. Those should be in the backlog (for the sprint or the release), and I don’t call them placeholders.

I’m not wild about having time-tracking stories in the sprint or release backlog because they need to be backed out of certain metrics such as number of stories completed (throughput). But I understand why organizations have them. Let’s call those time-tracking stories instead of placeholders.

By “placeholder stories” what I mean are stories for known-unknowns (or even unknown-unknowns) such as:

• we know we’ll have some production support work to do… 2 points

• we might have to do some sales support… 1 point

• we know we’ll have to do deal with some high priority defects that come up during the sprint… 3 points

• we could get interrupted for some high priority expedite work… reserve 8 points

• the build server is flakey and it might break again… 2 points

• “placeholder story for other unknown work that we might have to do”… 3 points

• end of release regression testing… 60 points

My main complaint is estimating them.

Visibility is Good

I’ve seen teams put a placeholder story in each sprint just as a place to keep record of their customer calls (mainly to get credit). They’ll add a line in the description or a (sub-)task for each new support call. I’m not completely opposed to the placeholder story itself in this case because it’s really just another type of time-tracking story. Also, making the work visible with sub-tasks is a fine idea. But estimating it is wonky.

Negatively Impacts Release Planning

Velocity is a useful input to sprint planning, but it is far more important and useful for release planning. If velocity includes defects and other placeholders, release planning actually becomes more difficult.

Keeping up with how much of the velocity the PO could bank on and how much will go to defects and other placeholders gets tiresome and is error prone.

When the Product Owner is considering the cost or duration of a batch of stories (for example, a new feature or an epic), that PO can’t just do simple math (backlog size / velocity). They have to ask someone to put placeholder stories for support work into the epic or they have to ask someone to tell them what’s the velocity of just the real user stories.

Placeholders make it harder to do what-if scenarios for the release: “What if we trimmed some scope and brought the release date in 2 months? What if we do this expedite and extend the release 1 month?” We have to consider where the placeholders fall in the backlog and scale them up or down. Or if there is a placeholder slotted in advance for every future sprint, then we have lots of placeholders polluting our backlog.

Estimating placeholders causes your velocity to be inflated relative to the backlog of known work for the release. Not estimating placeholders for known-unknowns will simplify release planning.

Therefore, don’t put placeholder junk in your velocity. If you use velocity or throughput for release planning purposes, and you probably should if you are making any release commitments at all, then your velocity metric should only count value stories — items in the backlog that the Product Owner or Customer wants, items from your story map and your Epic/Feature/Story decomposition.

Not Needed for Contingency

Some people use estimated placeholders for buffering in a release plan. They have to do this because they put points on everything, on all the unplanned stuff too. Don’t estimate that stuff. The unplanned and unknown stuff should serve to lower your velocity.

Track the historical rate of production support separately from your velocity. Track defect rates too. Understand the trend and distribution pattern across a release. Then take that into consideration when putting the release plan together. For example, that information helps me decide what to use for my planning velocity, how many or which sprints to include in the average and whether to adjust it further. It also helps me decide how many sprints of active development to plan for. If you take a week or a couple sprints at the end of your release to do regression testing, just plan for that in your schedule. You don’t need to put points on it.

Moving placeholders around as release dates change and adjusting them as the buffer is consumed gets tiresome. Worse, it’s a complication that creates unnecessary opportunities for error.

Plan releases conservatively: don’t include known-unknowns in your velocity; but do include known-unknowns in your release plan.

Not Needed for Sprint Planning

Usually when teams use placeholders it’s because they want to estimate story points for that work in order to reserve some capacity in the sprint. Putting a placeholder in every sprint and calling it 2 points to reserve capacity is unnecessary.

Plan sprints based on the amount of planned points of stuff the Product Owner wanted that you got done in the last sprint. If you use (sub-)tasks with hours estimates and an hours-based burndown, then reduce your capacity for these unknown things, but base it on how many planned hours for known-knowns you were able to do in prior sprints.

If your build server is flakey or if you need to do some maintenance on your VM server, either decide to fix it or don’t. Don’t put a placeholder in your sprint just in case. That’s poor planning.

Isn’t Relative Estimation

Relative estimation works when comparing like kinds of work — known-knowns and actual user stories. You don’t know how many production support issues you are going to have or how long it’s going to take to resolve them. Estimating that stuff is much less accurate than estimating known-knowns. General production support and other overhead shouldn’t show up as estimated items in your sprint or release backlog. Just let support activity be a drag on your velocity.

What About Defects and Expedites?

Defects should show up in your backlog once there is a specific issue that needs fixing — a known-known. Same for high priority expedite work. Add it to your sprint once it becomes a known-known.

But don’t estimate defects. Just let them be a drag on your velocity. Track the historical rate of defects separately. You can reserve capacity in your sprint and release plan without putting points on a placeholder for defects that haven’t been discovered yet.

Getting Credit for Work Done

If your team is using and estimating placeholders to get credit, Stop that. It’s a dysfunction in the organization if people feel the need to inflate their velocity or get credit.

Conclusion

There is no good reason to put points on placeholder stories. Keep unplanned stuff out of your velocity number. This leads to simpler and more conservative release planning.