Heads up! This page uses features your browser doesn't support. Try a modern browser like Firefox or Chrome for the best experience.

What teams do in a cycle

We can expand the in-cycle part of the Shape Up method into six steps:

  1. Kick-Off
    • Someone from the betting table informs the team members about the project and gives them the shaped pitch.
    • See: Hand Over Responsibility
  2. Orient
    • The team familiarizes themselves with the pitch and the existing system. They think of imagined tasks and start capturing discovered tasks by spiking experiments with real code and design.
    • See: Hand Over Responsibility
  3. Scope
    • After getting oriented, the team defines a single scope—the one thing to design, build, and wire together first. Later, after they’ve started building and discovered more tasks, they come back and map the work into more scopes to track, build and finish independently.
    • See: Get One Piece Done, Map the Scopes
  4. Build Vertically
    • With some scope defined, the teams build just enough UI and code to integrate and get that one thing working.
    • See: Get One Piece Done
  5. Report
    • When they feel due to show progress, team members plot the progress of scopes on the hill chart to show which still contain unknowns and which are fully solved.
    • See: Show Progress
  6. Ship
    • The team uses the scope hammer at every step to separate the must-haves from the maybes. They prioritize the most important scopes and solve the biggest unknowns first. Hammering the scope like this allows them to cut unimportant enhancements or nice-to-haves at the end of the project and ship on time.
    • See: Decide When to Stop

Looping through the steps

Diagram depicting how work looks over repeated application of the five main steps: Kick-Off, Orient, Scope, Build, and Report. At kickoff the map is an empty enclosure. At orient it is filled with dots. At scope one area is marked off inside the map. At build the area is partly shaded indicating completion. At report a dot moves up the left side of the hill. Back to build, the region is shaded further. At report again the dot moves over the hill. Back to scope, a new boundary is drawn in the map. At build, the second region is partially shaded. At report, a new dot appears on the hill for the new region at the lower left.

This illustration shows how the team loops through the process to get to the point where multiple scopes are in progress.

  1. Get oriented and capture some tasks
  2. Scope off where to start
  3. Build enough of that first scope to start seeing what the real work is
  4. Report uphill progress
  5. Build to solve remaining open questions and get over the hill
  6. Report progress at the top of the hill
  7. Map a new scope to work on next
  8. Build some of that
  9. Add that new scope to the hill

A designer’s path

In the diagram below, we see a designer moving through the steps of the in-cycle work. Note how most of the time is spent in the “build” phase.

Space-time diagram showing the path of a designer through the different stages of the build process

A designer and programmer

Here we see a designer and programmer interacting on a project. In this diagram the phase space under ‘Build’ is expanded into four different scopes (s1s4) that the team eventually mapped out.

Space-time diagram showing the overlapping paths of a designer and programmer through the build process

Note how the programmer spent more time in Orient getting familiar with the existing system. The designer, meanwhile, chose the first target scope and started building. After some time, the programmer followed up to implement the designer’s work in that scope. Both the design and programmer later go back to Map to carve out new scopes to work on. Sometimes the programmers follows the design; other times the programmer leads (see s3).

The lifespan of scopes

This diagram shows how the designer and programmers’ work integrated into finished scopes at different points of the project.

Space-time diagram of the designer and programmer paths overlaid with highlights showing when each scope started and finished

s1 was finished early. This is the “Get One Piece Done” idea in action. After that, s2 and s3 developed nearly in parallel, with s2 finishing sooner. A final piece of work, s4, was discovered at the end and quickly finished.

(Note: In practice, scopes always have meaningful names. They’re just presented abstractly here.)

Updating the hill chart

Finally, let’s see how and when the hill chart was updated.

Space-time diagram of the designer and programmer paths with hill chart snapshots shown at each visit to the report step

Note that the first update came after s1 was already finished. In this case, the team got the first piece done and the next couple scopes in motion before making their first hill update. After that you can see s2 and s3 making their way up and over the hill before completion. The last-added scope, s4, turned out to be easier to complete than expected. It moved over the hill in one day and they reported its first position at the far bottom right.

We built Basecamp to execute the techniques in this book. It puts all our project communication, task management, and documentation in one place where designers and programmers work seamlessly together. See How to Implement the Shape Up Method in Basecamp.