Estimating Placeholder Stories

Andrew had another good post over on Leading Agile, this one about whether you should estimate placeholder stories.  I liked Andrew’s post as I’ve had this same discussion with several clients recently and I think Andrew did a good job of explaining the reasoning behind it.

Effects on Release Planning

The main purpose of our velocity is to help with release planning.  It’s so the Product Owner can answer “when will we be done with X?” or “what will we have done by Y?”.  As such, only items that would be in your release backlog that the Product Owner would be looking at when considering such questions should be included in your velocity.  What the product owner cares about is at what rate can the team work through this backlog?  Ideally the product owner would be able to answer that without having to get someone to go populate a bunch of other stories.

Better Transparency

I believe there is also a major benefit to treating this other work as drag.  This other work is often work that doesn’t actually contribute to value for the customer.  Sometimes it’s red tape work that isn’t really necessary.  If we are treating it as drag we can show what kind of effect it is having on us delivering value.  It can be used as justification as well.  For example, let’s say there is a quality issue in production.  Incoming defects would increase and working on those would decrease our velocity.  We would be able to point that and show that our velocity has dropped due to these defects.  Maybe there is a concentrated effort we need to make beyond just fixing the defects to stop the bleeding?  Maybe the defects are the result of some poor practices we were doing somehow?  Whatever the case, we can now easily see the effect that the defects are having on our productivity.  When we give those points the effect is not as obvious.  The team is still producing the same velocity, so everything looks normal on the surface.

Getting Credit

Finally, it seems the most common reason I see for teams wanting to estimate these things is what Andrew hit on in one quick sentence.  They want to get credit for their work.

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.

Source: Estimating Placeholder Stories is a Bad Practice -LeadingAgile

This often comes about when changes in velocity would cause questions from leadership.  Isn’t that what we want though?  We want to be transparent about what is going on.  If we are having a lot of drag, shouldn’t leadership be able to see that and ask about it?  And shouldn’t we have an answer for them?  Maybe there isn’t a problem, and we should be able to tell them that.  Maybe there is a problem, and they might be able to help us.  Those conversations are good conversations.  Now if teams are getting punished or berated for dips in velocity, that’s definitely a problem the agile coach should be addressing with leadership and providing coaching to the leadership.

So, do you estimate placeholder stories?  What would happen if you stopped?  Check out Andrew’s original post over on Leading Agile and maybe he and I can change your minds.

The image at the top of this post, “Placeholder Stories”, is a derivative of “Placeholder” by Kevan, used under CC BY. “Placeholder Stories” is licensed under CC BY by Development Block, LLC.

Comments on this entry are closed.

%d bloggers like this: