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

The process for Joy Mapping

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:

• For the items which are clear, we create tickets labelled as 'initial work'. These factor in all the technical considerations.
• For the items which are not clear we create more tickets, with an additional label to 'investigate'. We prioritise these at the start. This ensures we surface the outcomes and prompt discussions as early as possible. We expect that we will create more tickets during build time from these.
• These tickets are linked to the related slice ticket using a number label. For example the first slice has a label '1'‚ and all the related tickets also have a label '1'.
• Each ticket contains a check list of the known tasks for it.
• We arrange the tickets in the order that makes the most sense. This will change as the work is in progress but gives us a good starting point.

Figure 24 - A template of a board with initial tickets

Figure 25 - Some of the initial work for the Insights chunk

The benefits of Joy Mapping

• Revalidating the product approach. The problem and solution is once more validated and described by a product person.
• Upfront awareness of the unknowns. The problem and solution is once more validated and annotated by an engineer. We highlight unknowns and prioritise investigating them at the beginning.
• Clarity and alignment on the initial approach. We start with a detailed description of problem and solution. From this crews can once again give asynchronous feedback and get more clarification.
• Low effort to kick-off. We don't need to think through everything up front. We expect there to be investigation and unknowns. We avoid a waterfall mindset.
• Labels enable learnings. As previously mentioned we label tickets as 'initial work', and if applicable 'investigate' Tickets added later will not be labelled with 'initial work'. This means that we can clearly identify items that we missed initially for future planning. It also makes it easy to identify why something took longer than we initially thought.