Shape Up Process: Building

Welcome to Process Street's Shape Up Processes template pack.

This pack will take you through the three key phases of Shape Up's development methodology: 

1. Shaping
2. Betting
3. Building

This template focuses on the last phase, building. The key concepts for this process include: 

• Breaking projects apart into scopes
• Downhill versus uphill work and communicating about unknowns
• Scope hammering to separate must-haves from nice-to-haves

The building phase is where you turn the shaped pitch into something shipable. Start this Shape Up Process: Building checklist by creating a new project and adding the team to it. Be sure to make sure each team member has access to the shaped pitch.

Use the form fields below to record basic information about yourself and the project.

Add the team members who will be working on the building of this project. 

The way to figure out what needs to be done is to start doing real work. Start by building something that is central to the project while still small enough to be done end-to-end—with working UI and working code—in a few days.

There are three criteria to think about when choosing what to build first:

It should be the core. Without it, the other work wouldn’t mean anything. 

It should be small. If the first piece of work isn’t small enough, there isn’t much benefit to carving it off from the rest. The point is to finish something meaningful in a few days and build momentum—to have something real to click on that shows the team is on the right track.

It should be novel. If two parts of the project are both core and small, prefer the thing that you’ve never done before.

Choose the piece to work on. 

Think of projects in two layers: front-end and back-end, design and code. Technically speaking there are more layers than this, these two are the primary integration challenge in most projects.

The point is to create a back-and-forth between design and programming on the same piece of the product. Instead of one big hand-off, take turns layering in affordances, code, and visual styling. Step by step, click through the real working feature-in-progress to judge how it’s coming and what to do next.

Each slice or piece of work integrates front-end and back-end tasks. This allows you to finish one slice of the actual project and definitively move on. That’s better than having lots of pieces that—fingers crossed—are supposed to come together by the end of the cycle.

Use the form fields below to summarize what you've chosen to work on and why.

The integrated pieces or slices of the project are called scopes. 

What is a scope?

Scopes: Parts of the project that can be built, integrated, and finished independently of the rest of the project. You break the overall scope (singular) of the project into separate scopes (plural) that can be finished independently of each other. 

The scopes reflect the meaningful parts of the problem that can be completed independently and in a short period of time—a few days or less. They are bigger than tasks but much smaller than the overall project. The header image provides an example of a completed scope map. 

Define and track the scopes as to-do lists. Each scope corresponds to a list name. Then any tasks for that scope go in that list.

To deal with different kinds of tasks and scopes that will come up Shape Up suggests using the following techniques. 

Layer cakes: Most software projects require some UI design and a thin layer of code below. Think of a database app where all you need to do is enter information, save it, and display it back. You can judge the work by UI surface area because the back-end work is thin and evenly distributed. 

Icebergs: If there is significantly more back-end work than UI work or vice versa. For example, a new feature that only requires submitting a form could require very complex business logic to return the right answer. This kind of work is like an iceberg.

Chowder: There are almost always a couple of things that don’t fit into a scope. In this case, allow yourself a “Chowder” list for loose tasks that don’t fit anywhere. But always keep a skeptical eye on it. If it gets longer than three to five items, something is fishy and there’s probably a scope to be drawn somewhere.

Upload/link the scope map in the form fields below.

To show the progress of a project without getting bogged down counting tasks and making numerical estimates Shape Up relies on the hill diagram. 

What is a hill diagram? 

Hill diagram: A diagram, shaped like a hill, used to show the progress of projects. Every piece of work has two phases. First, there’s the uphill phase where the individual is figuring out what approach to take/what they’re going to do. Then, once you can see all the work involved, there’s the downhill phase of execution.

The following task asks you to create a hill diagram to show the progress of the project and the scope's status. 

Combine the hill with the concept of scopes to create a hill diagram. 

The scopes give you the language for the project (“Locate,” “Reply”) and the hill describes the status of each scope (“uphill,” “downhill”). To see the status of the scopes,  plot each one as a different color on the hill. 

Use the form fields below to upload/link your hill diagram to show progress.

Share the hill diagram and show progress of the project. 

Use the "Members" field below to assign the next task to the Manager(s). This will let them know they can view, and approve the hill diagram in the following task. 

Recall that the six-week bet has a circuit breaker—if the work doesn’t get done, the project doesn’t happen. Having a fixed deadline motivates you to ask questions about what you're willing to trade-off and to limit motivations. 

Having a variable scope enables you to act on these questions. By chiseling and hammering the scope down, you can stay focused on the things you need to do to ship something effective that you can be proud of.

The aim is to actively make trade-offs and question the scope instead of cramming and pushing to finish tasks.

The following tasks will help you decide when to stop and will help you hammer the scope of your project. 

Hammer the scope.

People often talk about “cutting” scope. Shape Up use an even stronger word—hammering—to reflect the power and force it takes to repeatedly bang the scope so it fits in the time box.

As you come up with things to fix, add, improve, or redesign during a project, ask yourselves the following questions. Tick off the list as you go.

Decide if you will extend the project.  

In very rare cases, you'll need to extend a project. How do you decide when to extend a project and when to let the circuit-breaker do its thing?

First, the outstanding tasks must be true must-haves (tasks that must be completed for a scope to be considered done) that withstood every attempt to scope-hammer them.

Second, the outstanding work must be all downhill (think: hill-diagrams). No unsolved problems; no open questions. Any uphill work at the end of the cycle points to an oversight in the shaping or a hole in the concept. 

Even if the conditions are met to consider extending the project, it is still preferred to be disciplined and enforce the appetite for most projects.

Use the drop-down below to select whether you wish to ship or extend the project.

Sources

• Shape Up: Stop Running in Circles
  and Ship Work that Matters
• Process Street: Shape Up vs Scrum: 6 Months to 6 Weeks – How We Cut Our Dev Cycle 75%
• Process Street: Getting Started with Process Street
• Shape Up: Hand Over Responsibility
• Shape Up: Get One Piece Done
• Shape Up: Map the Scopes
• Shape Up: Show Progress
• Shape Up: Decide When to Stop
• Shape up: Move On

Related checklists

Shape Up Process: Shaping

Shape Up Process: Betting