The purpose of Joy Mapping is to achieve clarity and alignment on what the crew will build. And, what unknowns remain for the crew to investigate during build time.
This process runs between a product person and the relevant crew. Together they map out the slices of work the crew must build to deliver the features of the given chunk.
A slice represents a full stack testable and demonstrable unit of work. Slicing and building chunks this way enables earlier sharing and feedback from others.
The output is an initial project board in GitHub, completing the Joy Map helps us get there. Once the GitHub board is ready we no longer update the slices in the Joy Map.
Figure 21 Elements of a Joy Map document in Notion
Product creates an initial map of the slices. For each slice we describe the success criteria in the form of a list. For each item we describe the rationale. This process helps uncover gaps in the design. It also ensures that the chunk's challenges are completely solved.
Figure 22 A slice containing success criteria
Engineering reviews the map asynchronously. Once product has created the initial map, they share it with the crew. They will add comments, questions and any technical considerations. This promotes further asynchronous collaboration.
Figure 23 An initial slice with technical considerations
Product creates an initial GitHub project containing slices. Once the review finishes, product will create the initial slices in preparation for a kick-off meeting.
It is useful to have separate tickets for slices. This makes it easy for other stakeholders to see the broad progress while allowing engineers to focus on the details.
Product & Engineering complete the initial map in a kickoff meeting. There are several outcomes from this meeting:
Figure 24 - A template of a board with initial tickets
Figure 25 - Some of the initial work for the Insights chunk