One of the most common issues for Scrum Teams is what to do about work they expect to have to do during a Sprint, but don’t actually know the details about yet. Issues like these are quite common, and they cause Teams to have problems with their budgeting and planning for the Sprint. In Scrum-speak, we call these issues “ known unknowns.” The most common examples of known unknowns are:
- Fixing bugs in other systems.
- Going on sales calls with little warning
- Helping the systems’ people with common hardware and software maintenance issues
- Doing the day-to-day things that Managers find for Team Members to do
Since known unknowns are such a common problem, there must be a simple way to manage it, and there is.
Introducing the PlaceHolder Story
The solution is so simple that it’s actually elegant. The Team puts Stories in the Sprint Backlog in order to hold a budget for the StoryPoints that the Team knows it’s going to need to spend on these known unknowns. In Scrum-speak these Stories are called PlaceHolder Stories, as they hold a place in our Sprint Backlog for Stories in a general category that the Team doesn’t know the details about yet.
There are two basic ways to use PlaceHolder Stories:
1. Bugs to be Named Later
The Team can put Stories in the Sprint Backlog that will be replaced by the real Stories once they show up. For example, they might put Stories in the Sprint Backlog called ‘SouvSite bug_1’, ‘SouvSite bug_2’, ‘SouvSite bug_3’, and so on, each of which is a medium-sized Story that has been given a size of 4 StoryPoints.
2. Epic Consumption
The Team can create PlaceHolder Stories that are actually Epics which contain a number of StoryPoints that will be consumed as the actual Stories within the Epic show up. For example, the Team may have a Story called ‘SouvSite Bugs’ which has been assigned a size of 20 StoryPoints. As the actual bugs show up they consume the StoryPoints and the number of StoryPoints remaining in the ‘SouvSite Bugs’ Epic is decreased accordingly.
Other examples of the Epic-style PlaceHolder Story are:
Sales Support – containing StoryPoints that the Team expects to spend on sales calls they will be asked to assist in- Admin Support – containing StoryPoints the Team expects to spend helping admin
- Management Support – containing StoryPoints the Team thinks will be required to spend doing things like reviewing resumes, interviews for hiring new people, and other management-type overhead work that the Team’s people are required to do
- Chores – containing 30% of the total budgeted StoryPoints that the Team expects to spend on Chores within the Sprint
Don’t Forget the Back Burner
Of course, there is no guarantee that the Team will actually spend these StoryPoints that are set aside. It is critical that the Team makes sure that the Back Burner part of the Backlog has some Ready Stories that are ‘ready to go’ if the Team gets to the end of the Sprint and still has some unused StoryPoints left over – and also has the time to use them.
Go forth and create those PlaceHolder Stories.
And, if you want to learn more about them – We’ve got training for that.
As Always, Stay Agile.