Scrum, by its Agile definition alone, evolves. Scrum adapts and changes with the demands of its workplace environment. That’s how we’ve evolved to Scrum 3.0, the most Agile, scale-ready process framework yet. (To find out more about Scrum 3.0, read this.)
However, despite its evolution, there are Scrum Teams out there that are stuck in old-fashioned Scrum, especially when it comes to Sprint Planning.
- You completely plan and fill your Sprints based on StoryPoints.
- You budget a Sprint based on Velocity, rather than forecast a Sprint based on Doneness.
- You know you shouldn’t do this, but that’s your reality.
If this reality sounds like your Scrum Team, here is some guidance to help with your planning. One of the most common issues for Scrum Teams practicing old-fashioned Scrum 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 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.
The 2 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:
- 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 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.
Maybe It’s Time To Change With The Times
While the PlaceHolder Story is an outstanding tool for old-fashioned Scrum, there are groundbreaking Scrum processes that could make your PlaceHolder Stories obsolete, and help your Team be more successful.
If you want to explore this scale-ready Scrum, check this out.
And, if you want to experience Scrum 3.0 hands-on,
As Always, Stay Agile.