Multiple Choice:

  1. place-holder-story-scrum-agile-slackA placeholder story is a sign of sloppy planning
  2. All work should be known ahead of time and planned during sprint planning
  3. Yes, this allows the Product Owner to dump things into the sprint as needed.
  4. Sometimes we have a history of unexpected bugs/issues of handle it now. This allows us to track how much of that is showing up and leave some slack for when it does.
  5. We often have work we know we will have to do but, don’t know what it is yet.

Comment: This is a way to track how much unknown work is showing up and manage the amount by triggering a conversation when needed. One of the most common issues for scrum teams is what to do about work that we expect to have to do during a Sprint, but don’t actually know the details about yet, such as bugs we have to fix in existing systems, or expected sales support efforts. Using Place holder stories is a a method to manage these “known unknowns”.

7 comments
andrewmfuqua
andrewmfuqua

No, placeholder stories are not okay. Using and estimating placeholder stories to estimate the unknown is a very bad idea. Velocity is best used for release planning, not sprint planning. If you point work that was unplanned and include it in your velocity, your velocity will be inflated relative to the known work for the release that you need to burn down. This will cause you to overcommit for your next release. Your velocity should reflect planned work only. 

DanRawsthorne
DanRawsthorne moderator

@andrewmfuqua I disagree on two points here. First, PlaceHolder Stories are planned work; they represent known unknowns. Second, Velocity reflects Done work, not Planned work. In fact, at the Sprint level, the concept of 'planned work' is has been tossed out of scrum, to be replaced by 'forecast work' - which indicates that we know we don't know how much work we will actually do.

andrewmfuqua
andrewmfuqua

@DanRawsthorne I was too terse when I wrote "velocity should reflect planned work". Of course it reflects done work. I meant "velocity should measure the rate at which the known and planned work for the release is consumed (done), the rate at which the backlog is being implemented." What I'm really objecting to isn't even mentioned in this blog post, and that is estimating placeholders. 

DanRawsthorne
DanRawsthorne moderator

@andrewmfuqua @DanRawsthorne When Release Planning, it is almost always necessary to have buffers to handle the buffers for the "known unknowns" that will be encountered in the Release. The PlaceHolder Stories (or Epics) are a way to manage these buffers. In PM terms, PlaceHolders are contingency buffers... there are many ways to handle these buffers, but PlaceHolders are one of the easiest for most tools. You might also have one to handle the Management Buffer, which is used to handle the "unknown unknowns".

andrewmfuqua
andrewmfuqua

@DanRawsthorne Thanks for discussing this with me. Your challenges are helping me tune my thinking and wording...


If we're talking about things like bugs and sales support efforts, stuff that can happen at any time and generally happens all the time, (1) then estimating that stuff is much less accurate than estimating known-knowns so (2) don't estimate those things and let velocity measure the amount of known-knowns we can get done. 


The PO is managing a backlog of work. He or she wants to compare velocity against his/her release backlog. They want to do simple math in their head to know how many sprints it's going to take. If velocity includes other stuff, that velocity is inflated relative to what the PO cares about. In that case, when the PO 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 to 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.


Not estimating placeholders for unknown-knowns will simplify release planning.

DanRawsthorne
DanRawsthorne moderator

@andrewmfuqua @DanRawsthorne I certainly agree with the last sentence... however...

Velocity needs to measure how much work can actually get done, and takes into account the effect of impediments. The work that PlaceHolders represent are not impediments, so the work that just appears from nowhere must be (somehow) included in the Velocity.

Now, I agree (because Scrum is now more kanban(ish)) that we don't need PlaceHolders in the Sprints, since we can just bring Stories in and out as we need to... but some people still like them. For example, you often see Stories like "bug to be named later" inserted in a Sprint.

When estimating the StoryPoints that will be needed to release something, you know that you don't know everything that you need to know, so you must provide as-yet-unallocated StoryPoints to be used for the known unknowns. In PM terms, you need buffer... PlaceHolder epics are a good way to capture and manage that buffer...

If one doesn't have this buffer, then either you know you don't have everything you need, or you must treat new stuff like impediments, and bake them into the Velocity. Both of these solutions make the PM in me cringe...

So, I like the notion of unallocated SPs for Release Planning, and PlaceHolder Stories/Epics are a good way to manage them. As a Release Planner, I believe the PO must have data that tells him/her how many of these unallocated SPs to put in there - this is part of the due diligence of the Release Planner. And, by the way, I don't think that this should be done by the Team's PO - but that's another story.

andrewmfuqua
andrewmfuqua

@DanRawsthorne Thanks for the discussion. It was helpful, though I don't think either of us swayed the other. I admit, btw, that I used and estimated placeholders for Release Planning (not sprint planning) in the past (early on -- from 2000 through 2004). Moving them around as release dates changed and adjusting them as the buffer was consumed got tiresome. From '05-'09 I didn't use placeholders but did estimate defects as they came up.... and keeping up with how much of the velocity the PO could bank on and how much went to defects got tiresome. I tried placeholders for release planning again in 2010-2011. The last 4 years all my decisions have been toward whatever keeps unplanned stuff out of my velocity number and therefore leads me to simpler and more conservative release planning. Thanks again.

Trackbacks

  1. […] enough  to cope with the actual rate of change of requirements.    In fact, Chapter 4.4 on PlaceHolder Stories, the  discussion  of  the  mid-Sprint  Re-planning  in  Chapter  4.8,  and  the […]