Shape Up Process: Shaping

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

Shape Up started off as Basecamp‘s internal approach to developing and shipping software at lightning speed. It is now being adopted by Dev. teams across the globe, including the Process Street EPD team! The full approach has been clearly written (and illustrated), freely contributed, and easily accessible e-book: “Shape Up: Stop Running in Circles and Ship Work that Matters“. 

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 first phase, shaping. Shaping has four stages:

1. Setting boundaries
2. Roughing out the elements
3. Addressing risks
4.  Writing the pitch

When shaping, look at your current business and product priorities to determine what it is you want to address in the next build cycle. In shaping, the question is no longer “how long will it take to fix the problem?” (like in Scrum and other agile frameworks) but rather “how long are we willing to spend, to fix the problem?”

Use the form fields below to record key checklist details.

Later on, in the Shaping exercise, you'll be asked to bring in the technical experts. This comes before writing the final pitch. 

At this stage you'll want to reach out to some technical experts, this could be an Engineer, a Product Designer, and so on. You'll walk them through the idea of the pitch. You'll communicate the idea you are shaping as a potential bet, and ask for feedback. 

Use the dropdown below to assign technical experts.

The first step of shaping is setting boundaries on what you're trying to do.

Raw idea = Requests of feature ideas that are expressed in words and haven't been shaped. 

About the raw idea: Sometimes an idea gets you excited right away. If that's the case you need to set boundaries to temper the excitement on that idea. The boundaries check whether this is really something you're going to be able to invest time in or not.  It's important to stop and think about how valuable the idea is, we can all jump too quickly to either committing resources or having long discussions about potential solutions that go nowhere.

Other ideas are less exciting and feel more like a challenge. The customer wants a calendar; you don’t particularly want to build one, but feel you need to do something about the request. 

The way you deal with raw ideas is by setting an appetite:

Appetite =  The amount of time you want to spend on a project, as opposed to an estimate.

About the appetite: An appetite is completely different from an estimate. Estimates start with a design and end with a number. Appetites start with a number and end with a design. We use the appetite as a creative constraint on the design process.

Think of the appetite as a time budget for a standard-sized team.  The appetite usually comes in two sizes:

• Small Batch: A set of 1-2 week projects that a single team ships by the end of a six-week cycle. We batch these together into a six week cycle. 
• Big Batch: One project that occupies a team for the whole cycle. This project takes the same-size team a full six-weeks.

When deciding what feature to build you'll always start with a raw idea.

A raw idea: Requests of feature ideas that are expressed in words and haven't been shaped. 

For example: “customers are asking for group notifications.”

The essence of determining a raw idea is to avoid going down rabbit holes by discussing a solution. Once the raw idea is established, set some broad terms on the discussion to make it productive.

Key point: Be explicit in your answers so that they make sense when the data is pulled through into the final pitch. For example, if asked to "Input raw idea" write in the text field "raw idea = X feature".

With Shape Up there is no backlog so be sure to provide space for all ideas to be heard. AND be prepared to say no to the ideas that are less pressing.  

Set the appetite by defining how much of your time and attention the subject (raw idea) deserves. 

Appetite: The amount of time you want to spend on a project, as opposed to an estimate.

Answer the following questions to help you set your appetite. Then set the appetite in the form field below. 

Setting the appetite and coming up with a solution requires you to be critical about the problem. Ensure you give yourself both a realistic and achievable timeframe. 

Roughout how you plan to go about solving the raw idea.

Two things enable you to move at the right speed at this stage.

First: Have the right people—or nobody—in the room. Either work alone or with a trusted partner who can keep to your pace. Someone who has the same background knowledge, so you can jump between ideas with minimal explanations needed. 

Second: Avoid the wrong level of detail in the drawings and sketches. If you start with wireframes or specific visual layouts, you'll get stuck on unnecessary details and won’t be able to explore as broadly as you need to. 

It's called roughing out for a reason. Try to avoid getting lost in the details. 

Answer the questions to begin roughing out the elements. 

Don't forget to be explicit in your answers so that they make sense when the data is pulled through to the final pitch.

This task uses conditional logic. This means that what you select from the dropdown will influence which tasks follow using if-this-then-that logic. Conditional logic helps you mitigate time wasted on tasks that bring no value to this specific Shaping process. 

If your idea can be translated into words then the best technique for roughing it out is "breadboarding".

However, if it is more of a visual one and is difficult to put into words use then "fat-marker sketching". 

If you think that your idea can be put into words AND is a visual one, simply select both. 

Construct your breadboard. 

What is a breadboard?

Borrowed from electrical engineering, a breadboard is an electrical engineering prototype that has all the components and wiring of a real device but no industrial design.  A breadboard is when you:

Breadboard: Sketch and discuss the key components and connections of an interface idea without specifying a particular visual design. To do that, you can use a simple shorthand. There are three basic things to draw:

1. Places: Things you can navigate to, like screens, dialogs, or menus that pop up.
2. Affordances: Things the user can act on, like buttons and fields. 
3. Connection lines: These show how the affordances take the user from place to place.

When breadboarding with Shape Up use words instead of pictures.

Use the text fields below to record the components you're identifying and their connections.  Or, upload/link the document you used to record the breadboarding exercise. 

Draw your fat-marker sketch.

What is a fat-marker sketch?

Fat marker sketching: A sketch made with such broad strokes that adding detail is difficult or impossible.

Shape Up originally did their sketcher with larger tipped Sharpie markers on paper. Today they also do them on iPads with the pen size set to a large diameter.

Use the field below to upload/link a copy of your fat-marker sketch.

Before moving forward it's important to confirm you've understood the following three points: 

Room for designers: Now is not the time to bring in designers. By leaving details out, the breadboard and fat marker methods give room to designers in subsequent phases of the project.

Not deliverable yet: This step of shaping is still in your private sphere. It’s normal for the artifacts (or elements) at this point to be more or less indecipherable to anybody who wasn’t there with you. It's important to keep it that way for now.

No conveyor belt: Bear in mind that, at this stage, you could still walk away from the project. It hasn't been bet on, nor has it been committed to.

The Shaping process is designed to add value to the raw idea by making it more actionable. 

Once you've roughed out the elements and think you have a solution, it's time to take a hard look at that solution. 

The aim here is to find holes or unanswered questions that could trip up the team further down the line.

By addressing the risks you amend the solution, cut things out of it, or specify details at certain tricky spots to prevent the team from getting stuck or wasting time.

Well-shaped work looks like a thin-tailed probability distribution (like the image below). There’s a slight chance it could take an extra week but, beyond that, the elements of the solution are defined enough and familiar enough that there’s no reason it should drag on longer than that.

Source

Find and address rabbit holes.

What are rabbit holes?

Rabbit holes: Technical unknowns, unsolved design problems, or misunderstood interdependencies. Rabbit holes could mean that the project takes multiple times the original appetite to complete. 

You want to remove the unknowns and tricky problems from the project so that your probability (think of the graph from the previous task) is as thin-tailed as possible.

Aim for a project with independent, well-understood parts that assemble together in known ways.

Answer the following questions to address any possible rabbit holes:

Decide which roads you won't go down later on. 

Call out any cases you specifically aren’t supporting to keep the project well within the appetite.

This is where scope hammering comes into play.

What is scope hammering? 

Scope hammering: Forcefully questioning a design, implementation, or use case to cut scope and finish inside the fixed time box. 

There may be parts of the solution you got excited about during the sketching phase that are not really necessary. 

Use the text field below to note down any part (no goes) that are not necessary and can be cut from the original solution.

This task is for the Technical Experts to glance over.

Tech experts, check out the idea below and answer the following questions. 

Proposed Idea

Basic information

Created by:  {{form.Your_name}}

Role: {{form.Your_role}}

Date started: {{form.Today's_date}}

Idea and solution

{{form.Input_raw_idea}}

{{form.Set_terms_to_make_the_raw_idea_productive}}

{{form.Detail_what_you're_trying_to_solve}}

{{form.Explain_why_it_matters}}

{{form.Define_the_success_criteria}}

{{form.Determine_the_affected_customers}}

{{form.Establish_what_the_cost_of_doing_this_is_(instead_of_something_else)}}

{{form.Set_the_appetite}}

Risks

{{form.Have_you_missed_anything?}}

{{form.Have_you_made_any_technical_assumptions_that_aren't_fair?}}

{{form.How_exactly_would_a_user_get_from_the_starting_point_to_the_end?}}

{{form.Does_this_require_new_technical_work_you’ve_never_done_before?}}

{{form.Are_you_making_assumptions_about_how_the_parts_fit_together?}}

{{form.Have_you_assumed_another_design_solution_exists?_if_so,_which?}}

{{form.Is_there_a_hard_decision_to_settle_in_advance_so_it_doesn’t_trip_up_the_team?}}

{{form.Identify_no_goes}}

The “pitch” is the document you use to lobby for resources and collect wider feedback. Once you think you’ve shaped the idea enough to potentially bet on, formally write it up in what's up called a pitch.

What is a pitch?

A pitch is a document that presents a shaped project idea for consideration at the betting table. 

To re-cap, you and your team bet on different pitches in the betting table. 

The betting table is a meeting during the cool-down when stakeholders decide which pitches to bet on in the next cycle. 

To prepare for the betting table you must write a pitch that summarizes the problem, constraints, solution, rabbit holes, and limitations. Then the pitch goes to the betting table for consideration. If the project gets chosen, the pitch can be re-used at the kick-off to explain the project to the team.

The pitch consists of five ingredients:

There are five ingredients that we always want to include in a pitch:

1. Problem — The raw idea, a use case, or something we’ve seen that motivates us to work on this
2. Appetite — How much time we want to spend and how that constrains the solution
3. Solution — The core elements we came up with, presented in a form that’s easy for people to immediately understand
4. Rabbit holes — Details about the solution worth calling out to avoid problems
5. No-gos — Anything specifically excluded from the concept: functionality or use cases we intentionally aren’t covering to fit the appetite or make the problem tractable

The Pitch

Idea and solution

{{form.Input_raw_idea}}

{{form.Set_terms_to_make_the_raw_idea_productive}}

{{form.Detail_what_you're_trying_to_solve}}

{{form.Explain_why_it_matters}}

{{form.Define_the_success_criteria}}

{{form.Determine_the_affected_customers}}

{{form.Establish_what_the_cost_of_doing_this_is_(instead_of_something_else)}}

{{form.Set_the_appetite}}

Risks

{{form.Have_you_missed_anything?}}

{{form.Have_you_made_any_technical_assumptions_that_aren't_fair?}}

{{form.How_exactly_would_a_user_get_from_the_starting_point_to_the_end?}}

{{form.Does_this_require_new_technical_work_you’ve_never_done_before?}}

{{form.Are_you_making_assumptions_about_how_the_parts_fit_together?}}

{{form.Have_you_assumed_another_design_solution_exists?_if_so,_which?}}

{{form.Is_there_a_hard_decision_to_settle_in_advance_so_it_doesn’t_trip_up_the_team?}}

{{form.Identify_no_goes}}

Technical expert's input

{{form.Is_this_possible_in_the_chosen_appetite?}}

{{form.Is_there_a_way_to_simplify_the_existing_solution?}}

{{form.Is_there_a_hard_decision_to_settle_in_advance_so_it_doesn’t_trip_up_the_team?}}

{{form.Are_there_any_time_bombs_that_may_blow_up_mid-way_through?}}

For access to Process Street's version of Shape Up's betting process, click this template: Shape Up Process: Betting

Sources

• Shape Up: How to Begin to Shape Up
• Shape Up: Principles of Shaping
• 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

Related checklists

Shape Up Process: Betting

Shape Up Process: Building