Implement Shape Up: Cheatsheet

Justin Dickow
3 min readOct 2, 2020

--

An updated version of this cheatsheet can be found here.

This post is a quick overview and refresher on Shape Up, in the form of the pitch. Ask questions, discuss, or follow me on Twitter.

Appetite

Big Batch (6 weeks)

Small Batch (1 week)

Problem

We’re having a hard time acting and thinking strategically about our products, and our engineering teams are feeling like we aren’t accomplishing anything with an endless list of back log items, epics never being completed, and tasks only being a general reflection of the real work that needs to be done.

Solution

We’re going to start using Shape Up instead of Scrum, Kanban, Agile, etc. Product Managers will shape work out of cycle and 1–3 person teams will be assigned a single big batch project or a few small batch projects to complete within a 6 week cycle.

Shaping, Betting, Building Breadboard

The core elements of this solution are as follows

Shaped Work — In the form of a pitch, defines a specific problem the team is going to solve within an appetite, the general solution, constraints, must haves, nice to haves, and rabbit holes to avoid. The pitch is a thoughtfully written document that has explored many facets of the problem and potential solutions, and enables autonomy and accountability for the entire team

Problem — The struggle that we’re seeing and are motivated to solve for our customers

Solution — The core elements required to solve the problem

Appetite — How much time are we willing to bet on solving this problem?

Rabbit Holes — Anticipated details that have already been considered and de-risked in order to solve the problem within the stated appetite.

No-Gos (Or Out-of-Scope) — Areas that might be potentially explored by the team when trying to solve the problem that we’re explicitly asking them to avoid.

Once the pitch with the appropriate core elements has been handed over to a team as a project, they have only a few responsibilities besides completing the work and solving the problem.

Discovered Tasks — The team gets to work right away on solving the problem. This means building, designing, and slicing up work into integrated chunks. As the team is working, they’ll discover tasks that will need to be completed as part of their solution. These tasks should be tracked. If a task is a nice-to-have, we’ll mark it with a ~ so everyone can tell what’s a must-have and what’s a nice-to-have.

Scopes We’ll bucket tasks into structured pieces of work that can be completed independently of other buckets.

Nice To Haves

  • ~Breadboards — A text-based sketch within the pitch of the key places, connections, components, information, and affordances needed to solve the problem. Leaves plenty of room for engineers to do their job.
  • ~Fat Marker Sketches — An image-based sketch within the pitch, drawn using broad strokes to further describe a visual concept when the arrangement of elements on screen is a fundamental part of the problem being solved. Leaves plenty of room for designers to do their job.
  • ~Betting Table — An in-the-loop team of stakeholders meeting to decide which pitches to bet on in the upcoming cycle, assign teams, and hand over responsibility.
  • ~Cool Down — A period of time after the completion of a cycle, generally 2 weeks, in which the teams can work on whatever they want.

No-Gos

  • Grab Bags — We won’t do ‘redesigns’, ‘refactors’, ‘version 2.0s’, or the like. We’ll solve specific problems and leave the code base and design better than we found it.
  • Backlogs — The teams don’t need to be concerned with potential future tasks. If an idea or problem is important enough to bet on, then it will come back in the form of a pitch. Individuals can keep their own lists.
  • Imagined Tasks — Tasks that we think we need to do, before the team has started solving the problem, don’t need to exist. Instead we opt for discovered work

Ask questions or follow me on Twitter

--

--