What Is a Parking Lot Diagram
A parking lot diagram is a way to visually communicate status of work on a product in the context of major blocks of functionality intended to deliver a specific outcome.
The parking lot diagram uses boxes to indicate the relationship between the different levels in a product functionality hierarchy, and uses color to indicate the status of significant functionality.
The parking lot diagram was originally created for use in Feature Driven Development (FDD) to communicate status at various levels of functional hierarchy. The diagram is called a parking lot diagram because the boxes representing different levels of the hierarchy look like a graphical representation of a parking lot with cars parked in the spot.
An Example
Below is an example parking lot diagram for a portion of an ERP system.
For the purposes of this technique brief, you can think of the big boxes labeled as the key business areas that the product supports (for example Order Processing), and the boxes inside those business areas as the epics that the team is working on to support specific activities (for example Create New Order).
When to Use a Parking Lot Diagram
The parking lot diagram is best suited as a status reporting tool, especially for complicated products where work is being done on several business areas and epics at the same time. The parking lot diagram provides status at a glance which signals people interested in the product a pointer to what questions they should ask for further information.
A parking lot diagram is helpful whenever you maintain a hierarchy in your backlog where you have large items that are broken down into smaller items.
Why Use a Parking Lot Diagram
While the parking lot diagram does not directly indicates status based solely on outcome, it does provide more context to guide the team to determine if they are working on the right thing.
In contrast, burnup and burndown charts show total number of backlog items completed without regard to context. It’s possible that without the further context that the parking lot diagram provides, a team could produce a lot of the wrong things quickly.
The parking lot diagram also provides a way to display status in terms of human judgement. The status of each epic (Done, In Progress At Risk) is based on human judgement, not direct application of a rule based on the number of user stories completed. This allows teams, particularly product people to indicate how each epic is doing to deliver the outcome. It also can lead to epics being considered complete before all the corresponding user stories are done.
How to Use a Parking Lot Diagram
It’s best to create a parking lot diagram when you start work on a product so that the team can become accustomed to maintaining the diagram as they proceed, and so that those outside the team grow accustomed to using the diagram to understand status.
If you are in the midst of product work, you can still adopt a parking lot diagram. You may need to do a bit more explanation for those who are updating and those who are referring to the parking lot diagram so that they understand it’s purpose.
- Identify the person (or people) who will maintain the parking lot diagram. This person will not be the only one who can update the parking lot diagram (it’s best if all teams can update the diagram) but they are responsible ensuring that the diagram is up to date.
- Identify the key subject areas under revision on your product. These become the large boxes on your parking lot diagram.
- Identify the specific epics or activities within each subject area. These become the colored boxes inside the subject areas.
- Identify the number of backlog items contained within each epic and determine the target release or deployment for each epic. If you do not know this information for a particular yet, leave it blank. Don’t feel compelled to provide that information solely for this purpose.
- If you are in the midst of product work, poll each team and update the parking lot diagram to reflect current status. This includes:
- Indicate the number of backlog items related to that epic that are complete
- A judgment on the state of a given epic: Work has not started, work is in progress, the epic is done to the point that it can provide progress toward a given outcome, or the epic is at risk and needs some help.
- The given release or deployment for which the epic is targeted.
- Indicate the number of backlog items related to that epic that are complete
- A judgment on the state of a given epic: Work has not started, work is in progress, the epic is done to the point that it can provide progress toward a given outcome, or the epic is at risk and needs some help.
- The given release or deployment for which the epic is targeted.
- Notify everyone interested in the status of product work that the Parking Lot Diagram is the main means of viewing this information. Provide a brief introduction to how to read the diagram, especially noting the human judgement part of epic status.
- On a regular basis, at a minimum each iteration, update the parking lot diagram to reflect the current status of the product.
Caveats and Considerations
It’s possible (and quite desirable) that you will have some epics that are considered done even though all the backlog items for that epic are not completed. Human judgement is important for setting status because it allows teams and product people to focus on the outcome (the reason the epic exists) rather than output (count of backlog items) to determine status. You may initially identify a set of backlog items that you think are necessary to deliver the goal of the epic. Then as you start work on those backlog items you find out you can deliver on the purpose of the epic with a fraction of the total number of backlog items. The opposite may also happen where as you begin work on an epic and realize you may need to do more or different items than you originally thought.
It’s extremely important that people treat the status indicated on the parking lot diagram as an indication for further exploration rather than a red flare that incites punishment or blame. People need to feel safe in indicating that their epic is at risk so that they can get help. If people do not feel safe proclaiming their epic at risk because they are afraid of the repercussions, they will avoid setting that status until it’s too late to recover the at risk epic.
I’m not aware if any of the current agile work tracking tools (such as Jira, CA Agile Central or VersionOne) can currently produce parking lot diagrams. Mike Griffiths does provide an excel spreadsheet you can use to produce parking lot diagrams.
If you are using SAFe, the large boxes could be considered epics, the small colored boxes are features and the numbers of total and completed are user stories.
In Feature Driven Development (FDD) the large boxes are feature areas, the smaller colored boxes are feature sets, and the numbers of total and completed are features (as defined in FDD).
If your backlog is a two level hierarchy, you may not have the large boxes and just show the small colored boxes which represent epics – things your customer or stakeholder identified and the numbers of total and completed are user stories – backlog items your team identified to deliver the larger epic.
Additional Resources
Summarizing Progress with Parking Lot Diagrams
