From sprints to cycles, and from product backlogs to …well…no backlog at all. These are just a couple of examples of the differences between Shape Up and agile approaches such as Scrum.
But, what exactly is Shape Up? How does it, when put into practice, differ from Scrum?
Our development team here at Process Street recently made the move from Scrum to Shape Up and I asked them how the two compare. This post outlines the key takeaways from the team and takes a closer look at what Shape Up is as a whole.
To jump to a specific section, click the appropriate link below:
- A re-cap on the Scrum workflow
- What is Shape Up?
- How does Shape Up work?
- Scrum vs Shape Up
- Shape Up at Process Street
- Key takeaways: From Scrum to Shape Up
Alternatively, to read the whole post – just keep on scrolling. 🚀
A re-cap on the Scrum workflow
Scrum is an agile framework based on the sprint system, or “incremental releases”, which take from 1 to 3 weeks to complete. You continue the sprint until the project is feature complete. Each independent project may run multiple sprints until all the features have been built.
Scrum relies on three key roles, three artifacts, and three ceremonies. Let’s go through each of these in more detail.
Scrum’s 3 key roles:
- The product owner: The person responsible for defining the required product features The product owner thinks up the ideas that turn into products.
- The scrum master: The leader, and protector of the team and the process. Running the meetings and keeping things going.
- The team: Anyone else involved in building the product.
Scrum’s 3 Artifacts:
- Product backlog: Product owners create a prioritized list of features, known as user stories that could benefit the product. This list evolves and changes priority with every sprint.
- Sprint backlog: The highest priority user stories go into the sprint backlog these get estimated for size and are committed to for the next sprint.
- Burndown chart: Shows the progress of the sprint, based on tasks completed in the sprint backlog. The aim of this chart is to approach 0 points as all tasks are completed.
*User stories are a way of describing a feature set. For example, as a Process Street user, I need a wider range of HR checklists, so that I can better manage my HR workflows better. To learn more about Process Street and what we do check out our explainer video.
Scrum’s 3 Ceremonies:
- Sprint planning: The product owner, scrum master, and the team meet to discuss the user stories. Together they estimate the relative size of each story when broken down into tasks.
- Daily scrum: This is a brief catch up where the team discusses what they have completed since the previous meeting, what they are working on, and report on any blocks they may be facing.
- Sprint review or retrospective: Occurs at the end of the sprint, where the team demonstrates the completed work to the product owner. In sprint retrospectives, the team discusses what they can do to improve the process going forward into the next sprint.
Now we know what Scrum is, let’s take a look at Shape Up and how it compares…
What is Shape Up?
Shape Up is Basecamp’s development methodology. Basecamp is a project management tool that has been putting Shape Up into practice for the last 15 years. To learn more about Basecamp itself, check out the Youtube video below.
In 2019, Ryan Singer, head of strategy and product at Basecamp, put the Shape Up approach down on paper in the digital book “Shape Up: Stop Running in Circles and Ship Work that Matters” which you can access for free here.
“Shape Up is for product development teams who struggle to ship. If you’ve thought to yourself – Why can’t we ship like we used to? or I never have enough time to think about strategy,- then this book can help. You’ll learn language and techniques to define focused projects, address unknowns, and increase collaboration and engagement within your team.” – Ryan Singer, Stop Running in Circles and Ship Work that Matters
How does Shape Up work?
Unlike the Scrum approach, Shape Up uses cycles rather than sprints. As you can see from the diagram the cycles work on parallel tracks. The upper cycle includes anyone who is shaping and/or placing bets, and the bottom cycle includes those who are building. This means that people who are shaping and betting run in unison with those who are building.
What does shaping, betting, and building mean?
Don’t worry I’m getting to that…
Within the cycles, there are three key stages: shaping, betting, and building.
Shaping has four stages: setting boundaries, roughing out the elements, addressing risks, and writing the pitch.
In the shaping process, you look at your current business and product priorities to determine what it is you want to address in the next build cycle (remember the section above). 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 on fixing the problem?”
In shaping, the amount of time dedicated to solving each problem is called the “appetite“. The appetite determines how many weeks your team is willing to spend building the solution to a problem, and this time frame sets the boundary for the solution. Shape Up’s approach has an appetite size of a small batch of 2 weeks or a big batch of 6 weeks. None of the build cycles are longer than 6 weeks.
In the search for a solution, teams use a variety of techniques to rough out the elements of the solution (all of which are detailed in the book). One technique is “breadboarding“, which involves laying all the different components of a solution out on a physical device (imagine a breadboard with components laid out on it 🍞). Another technique, “fat marker sketching” involves well… fat marker sketching out the solution.
Ultimately, in both techniques, you are sketching out how the proposed solution is going to work. All of the breadboarding and fat marker sketching goes into the “solutions” part of the pitch.
Rabbit holes are where you try to think up any possible risks that could occur and find a solution to them. Or, in other words, any technical rabbit holes that could distract from the project itself and cause it to take longer to ship. 🐇
No gos are similar to rabbit holes in that they could also cause the project to go on longer than the appetite allows for. No go’s mean fencing off anything that may be tempting to work on during the build of the solution. This is where you purposely say “we are not working on this .. no matter how tempting”. ✋🏽
To determine the risks, get a designer in the room, a service provider, a programmer, basically anyone who could be involved in the solution.
“Here is my proposed solution to solve this … problem, what am I missing?”… “What could turn this from a 6 week build to an 18 week build?”
Involve the team and ask them to consider all of the possible ways that this could triple in length. Try to solve each of the problems or risks that arise – write down how you are going to avoid these problems to ensure the solution is shipped on time. If you can’t find a solution for the risk then it means you are not ready to solve the problem and pitch the solution.
Once the boundaries have been set, the elements roughed out, and risks addressed, it is time to write the pitch. This is a document that forms the structure of your project and solution.
Betting 🃏 💸 🏇🏻
At the start of each cycle, there will be a number of pitches. To choose which pitch to run with the Shape Up approach uses a betting table. This allows team members to choose which pitch they want to bet on for the next build cycle. The more bets and the more superior the person betting, both account for the selection of which pitch/ pitches will be chosen for each cycle.
*On a side note 🧠: Basecamp is a smaller company so its “betting room” is easy to manage. Working in a larger scale company, with say 1000 engineers would be a different kettle of fish.
If this were to be the case you could choose a few pitches for each cycle or group betting tables by department or team.
The most important thing about the betting table is that you always start with a clean slate. This means that pitches from the previous cycle’s betting table should not spill over.
Building 🏗 🗺 🤖
Building consists of 3 stages: getting one piece done, mapping the scopes, and forming the hill chart.
At Shape Up, they recommend building in a vertical slice. Building in a vertical slice means focusing on getting one thing done as quickly as possible to gain momentum in a project. The important difference here is that “done” means both frontend and backend elements. Build each end together.
For example, if you are building a button ensure that every element (both back-end and front–end) is complete before marking it “done”.
Once you’ve got one thing done you allow yourself room to start mapping the scope. The core idea here is that you map the scopes as you go.
Hill chart ⛰ 🏞
By mapping the scopes as you go, work begins to take the form of a hill. The hill starts at the bottom (left in the diagram), as you work on solving the problem and all of its corresponding elements you start climbing up the hill.
As you’re figuring out all of the unknowns, you keep moving up the hill. But, there reaches a point where you solve all of the problems or there are very few left. And the rest is execution, that’s when you start going downhill (right side of the diagram).
In the hill diagram above you can see that there are 3 scopes that are being worked on, and you can see where each of these scopes stands. There are a bunch of unknowns for the “future-applying edits” scope on the uphill, but on the downhill, there are two scopes that are problem-free and are simply being executed. So, imagine the question “how far along on a project are you?” The answer is made simple by using this method.
Now you have an understanding of what Shape Up is, let’s take a look at some of the key differences it has to Scrum.
Scrum vs Shape Up
“I think the biggest change is ownership of solving the problem feels way more shared. Everyone on the team is empowered to solve the problem regardless of their role.” Madison Kaylo, Product Manager at Process Street
To approach this section I’ll compare Shape Up’s fundamental concepts to that of Scrum (rather than the other way around).
Remember in the “betting” stage I introduced spillover? One key difference between Scrum and Shape Up is that Scrum relies on a backlog, while Shape Up completely rejects the idea.
Think about a product backlog, there will likely be user stories in there that are dated. These stories will slowly begin to surface and they may have been sitting in the backlog for as long as 12 months. Therefore, the feature request, or whatever the original problem was, has likely already been solved.
Whatsmore, by Shape Up refusing to allow spillover, each and every cycle is started with a clean slate. No pitch gets spilled over to the next cycle. Should the same problem continuously arise in different pitches, then it will be dealt with as per the new pitch that’s put forward for the cycle. This leads me to my next point …
Betting and putting forward pitches
Compare the planning stages for each approach … at Shape Up planning is very different than in an agile framework. Here the pitches do not go into every tiny detail, things are not laid out with every single task broken up and carefully assigned out. Taking on a pitch requires a substantial amount more autonomy and therefore, responsibility.
Mapping the scopes
As I mentioned earlier, with Shape Up, you build your own scopes as you go. This highlights the difference between “agile tasks” which is what you get with Scrum. With agile tasks at the very beginning of a project, somebody sits in a room and imagines all the tasks that are going to be happening in the coming sprint. This person then writes down what the imagined tasks could be as best they can. The problem with this approach is that when it comes to actually writing the code further down the line, it’s often not the same person writing who did the imagining in the first place. Do you see how this could start to get confusing?
Mapping the scopes as you go by the person working on the project itself allows for realistic time frames to be assigned to each scope. It also allows for the Hill Diagram to be created and shared with the team with ease so that everyone has access to the progress of a project.
Shape Up at Process Street
In order to get a real feel of Shape Up in practice, I asked Mike Schutte from our Product Development team to summarize our transition from Scrum to Shape Up. His key takeaways include: Be thoughtful. Communicate exceptionally well. Let the end-user be your north star.
I’ll let Mike take it from here …
This is the refrain that hummed in my mind as I read through this profound and pragmatic book on managing the creation of a product. While written from the perspective of a software team, the principles of Shape Up apply to any group or individual seeking to make something of quality (or dare I say Quality).
Be thoughtful 🤔
…”We don’t do daily stand-ups, design sprints, development sprints, or anything remotely tied to a metaphor that includes being tired and worn out at the end.” – Jason Fried, Co-Founder & CEO of Basecamp
This early declaration in the book’s forward resonated deeply. A sprint is definitely an intense, and telling, metaphor for the somehow default way of doing things. Sprints have a deceptive sheen to them since the standard length of two weeks is incredibly short. Maybe it also seems sexy because sprinting, at least to me, connotes physical strength or health. The notion of moving the proverbial needle in two weeks is no doubt enticing.
In reality, it is unsustainable. Product development is not a footrace. It’s more like a chess match. It takes consideration, strategy, patience, and sacrifice. Instead of picking a direction as fast as possible and getting there as fast as possible, Shape Up encourages you to think carefully about the direction you’re going. To think critically about how you’re going to get there.
Time estimates → appetite declarations
Changing time estimates to appetite declarations is a revelation. Instead of asking “how long will this take?”, you ask “how long are we willing to spend on this problem?”. The result of the latter perspective yields, I’d argue, more innovation because the temporal constraint precludes “doing it the way it’s always been done” because that way might take too long relative to the allotted appetite (see the Dot Calendar example).
Communicate exceptionally well 🗣
Shape Up bubbles up from the springs of programming concepts like layers of abstraction and separation of concerns. These cognitive methods are applied to communication patterns and process design, resulting in better communication. Each phase of Shape Up has a distinct and predetermined purpose, allowing people to be on the same page. While the all-hands whiteboard brainstorming session might sound exciting, that kind of thought jazz is not reproducible or reliable. You gotta swap the jazz trio for an orchestra.
Exceptional communication is at the heart of Shape Up. Clear and precise communication allows the team to have certainty of being on the same page and moving in the same direction. From the genesis of shaping an idea with fat markers to describing the progress of a scope using hill charts, Shape Up pushes teammates to get out of their inscrutable heads and into a more collective consciousness.
Let the end-user be your north star 🌟
Thinking with Shape Up glasses on, you’re not concerned with the absolute best solution. You’re concerned with the specific best solution given the time constraints of the appetite and the data at hand on the problem. Wasting weeks on a complex animation for a problem that had more to do with usability than visual engagement is a fool’s errand, but it can feel like a productive and noble cause.
Given the time you have, and the problem the user is experiencing right now, choosing the “best” solution is easy. It’s the one that alleviates the defined problem within the specified appetite.
Shape Up is an excellent read for any maker. Regardless of leadership level or functional role, it encourages you to think intentionally and make calm decisions rooted in practical constraints. Even if you’re not on a team that practices the Shape Up orthodoxy, the ideas and questions posed in the book can absolutely benefit your personal approach to how you make things.
And … there we have it. Thank you Mike for the insightful feedback on Shape Up in practice at Process Street.
Key takeaways: From Scrum to Shape Up
- They both have a fixed time frame, for Scrum these are called Sprints, and projects can roll over from one sprint to the next. In Shape Up the time frames are called appetites, which are capped at 6 weeks, projects can not roll over to the next cycle.
- Within both approaches, the scope is flexible… to a certain extent. Providing a project meets the intended objective of the Bet (for Shape Up) or the Sprint (with Scrum), flexibility is permitted.
- The team is included in the decisions concerning any project they may be included in. The difference is when other team members are brought into the project.
- Unlike Scrum, Shape Up has no Product Backlog and advocates against the use of a backlog.
- Shape Up’s pitching method requires a substantial amount more autonomy on the part of the team members who take on a pitch. This is because pitches are broad, and the tasks are not individually laid out and assigned beforehand, unlike in Scrum.
- Shape Up works well for Basecamp which has a smaller team and although scaling would be possible through the use of a few workarounds (like selecting multiple projects in the betting process/ breaking up betting departmentally) there is no prescriptive approach offered to accommodate larger teams. Although, the same can be said for Scrum at least there are scaling agile frameworks available.
If you’re deciding whether to make the move from Scrum to Shape Up we’d love to know what drove you to make that decision. Or, if you’re currently implementing Shape Up’s approach, let us know how you find it in the comments below. 👇🏼
Great article 👍 Shape Up in 10min. thank you
Thanks! I’m glad you enjoyed it.
You summarized the shape up book, but I would rather hear what worked, what didn’t, what surprised you, what was a hard adjustment? How did you convince the product team to just abandon a feature when it wasn’t done in time? The title says you cut your dev cycle by 75% – what does that specifically mean?
Hey Bekki, thanks for your comment. All of your questions are valid and I’d like to write a post in the near future to answer them all after we’ve put the Shape-Up approach into practice for a longer period of time. Watch this space!
Hi Molly! Thank you for the review! I am a follower of Basecamp & their work! I love their content!
Question- If shape up doesn’t have a backlog, how do you manage reported/verified bugs?
Heya, thanks for reaching out! It depends on the bug, when following the Shape Up process it’s during the cool-down period (between each cycle) that issues such as bugs can be dealt with. The key thing is to look at the bug and ask what is the appetite for that bug, how long are you willing to spend resolving it? This can be based on the percentage of users the bug is affecting, the time it will take to resolve the issue, and so on.