Shaping Process

Two-week agile sprints are so focused on delivery, they don’t leave much time to collaborate and properly scope features. Additionally, with a lot of team members new to working on digital products, some don’t know what kind of feedback to provide or are afraid to speak up with their insights. We often miss things that should have been taken into account. Inspired by the book Shape Up: Stop Running in Circles and Ship Work that Matters by Basecamp’s Ryan Singer, we’re trying to solve these problems by exploring ways to slow down our process into cross-functional phases and allow for more collaboration and teaching moments during both the design and build phases.

What is shaping

Property 1: It’s rough

“Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge.”

Property 2: It’s solved

“Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. The work isn’t specified down to individual tasks, but the overall solution is spelled out. While surprises might still happen and icebergs could still emerge, there is clear direction showing what to do. Any open questions or rabbit holes we could see up front have been removed to reduce the project’s risk.”

Property 3: It’s bounded

“Lastly, shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out.”

“Taken together, the roughness leaves room for the team to resolve all the details, while the solution and boundaries act like guard rails. They reduce risk and channel the team’s efforts, making sure they don’t build too much, wander around, or get stuck.”

What’s working for us

We’re using a modified version of Basecamp’s process that fits into our two-week sprint cycle and takes into account that we have a single team, not a separate team for shaping and one for building. We’ll modify these steps as we use the process more and learn. This is what has worked, so far for a single project.

Phase 1: Define the scope

The purpose of this phase is to get everyone on the same page with regards to the scope of the problem we’re solving.

“First we figure out how much time the raw idea is worth and how to define the problem. This gives us the basic boundaries to shape into.”

Step 1.1: Start with the raw idea

Somebody on the team puts forth a raw idea for a project we want to work on. We all discuss the merits of the idea and decide whether it’s something we want to shape.

Step 1.2: Understand the problem

We either pull from existing research or conduct new user (or other appropriate stakeholder) research to ensure we fully understand the problem.

Things that can help us understand the problem include:

• User interviews

• Stakeholder interviews

• Usability testing of current state

• Personas/user types

• User scenarios

• Journey maps

• Current state walkthroughs

• Analytics analysis

• Product problem statement and vision

Step 1.3: Narrow the problem

Once we understand the problem, we can decide which portion we want to solve now and nail down a concrete problem statement.

Step 1.4: Determine appetite

Determine how many sprints worth of work we’re willing to dedicate to solving the narrowed problem. We also consider that we’ll be working on other things, so it may actually take longer than the stated number of sprint.

Phase 2: Generate ideas

The purpose of this phase is to come up with ways to solve the problem within the appetite

“Then comes the creative work of sketching a solution. We do this at a higher level of abstraction than wireframes in order to move fast and explore a wide enough range of possibilities. The output of this step is an idea that solves the problem within the appetite but without all the fine details worked out.”

Step 2.1: Sketch solutions

We conduct offline sketching either alone or in pairs to come up with possible solutions to the problem.

Solutions should be at the level of breadboarding or fat marker sketches answer these questions:

• Where in the current system does the new thing fit?

• How do you get to it?

• What are the key components or interactions?

• Where does it take you?

• List out the elements of the solution that are important to solving the problem.

Step 2.2: Review sketches

We reconvene to present and discuss all of our ideas and vote on which to move forward with. We also decide whether we want to do another round of sketching before moving to the next phase.

Step 2.3: Narrow down options

Pick one or two viable options to poke holes in and flesh out in further detail.

Phase 3: Ground in reality

The purpose of this phase is to make sure the selected solution is feasible in the real world.

“Once we think we have a solution, we take a hard look at it to find holes or unanswered questions that could trip up the team. We 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.”

Step 3.1: Poke holes in selected option(s)

Offline, we each take a look at the selection option(s) with an eye to:

• Make sure the solution will work with real data and content

• Think through risks and rabbit holes

• Run through user scenarios

• Combine options to make a feasible whole

Asking questions like:

• Is this possible within the timeframe?

• Did we miss anything?

• Are we making technical assumptions that aren’t fair?

• Does this require new technical work we’ve never done before?

• Are we making assumptions about how the parts fit together?

• Is there a hard decision we should settle in advance so it doesn’t trip up the team?

• Are there pieces of the solution that aren’t necessary to solve the problem?

• What else do we need to learn?

Step 3.2: Review hole poking findings

We reconvene to present all of our ideas and come to a consensus on which to move forward with. We also decide whether we want to do another round of hole poking before moving to the next phase.

Step 3.3: Choose option to move forward with

Decide what we need to document about the solution so we don’t forget.

Phase 4: Scope for build

The purpose of this phase is to prepare the solution to be built.

Step 4.1: Organize the project into scopes

Separate the project into the chunks of work to be done:

• Organize by structure, not by person

• Organize into functions that can be completed together into working pieces

• Meaningful pieces that can be completed in a few days or less

Practical application: Use one GitHub issue for each scope and the checklist feature within the issue for the list of tasks.

Step 4.2: Determine scope order

How to determine order:

• Start with the most important problems with the most unknowns.

• The goal is to leave the easiest and least important stuff for last.

Phase 5: Build

The purpose of this phase is to build the solution, ironing out details as we go.

Step 5.1: Get one thing done

Identify something core, small, and novel that can be used to show progress and solve a key problem. Build just what’s needed to get to the piece you’re starting with.

Step 5.2: Refactor scopes and tasks as we go

As we go:

• Identify tasks for each scope

• Adjust the task list as unknowns become known

• Refactor the scopes, as needed

Step 5.3: Decide what will be good enough to be considered done

Flag nice-to-haves and compare against baseline instead of ideal.