At Teamscope we started implementing the Shape Up Method in 2020. Here are what Shape Up is, why it's a brilliant product development method and the results we obtained at Teamscope after two years of applying it.
What is the Shape Up Method?
The Shape Up Method is a product development method that helps teams prioritise and develop products. Basecamp created Shape Up in 2019 and is companies like Mixpanel, Fontawesome, and Maze.
The core principle of Shape Up is the concept of Fixed time, variable scope. Let's break that down.
- Fixed time: Teams define a cycle length, usually between 3 to 6 weeks. At the end of the cycle, the bell rings, and what the team got done gets shipped. Within Shape Up, there is no deadline extension, and when time is up, it's up.
- Variable scope: Shape Up does not rely on traditional linear planning. Unlike Scrum or Waterfall, there is flexibility to adjust the scope of work during the cycle if needed. For example, the team can leave out certain features or make them simpler.
Key benefits of Shape Up Method
Forget the burden of never-ending backlogs
With Scrum, pending features go into a backlog list. This list is usually kept in Jira, Trello or Github issues. As time goes by, this list grows, becoming a never-ending burden.
Shape Up eliminates pending features, and any idea of improving a product goes into a pitch.
A pitch is not a pending feature, and its existence does not mean it will ever be built. A pitch may live as a pitch for eternity until the team feels there is consensus that the feature should implement it.
Steady cadence and predictability
Cycles on Shape Up have a defined duration (between 3 to 6 weeks). After them comes a cool-down week, and the process repeats perpetually.
This structure brings rhythm into product teams and, with it, the ability to learn what is their true bandwidth and capable within the constraints of a cycle.
Before the start of each cycle, the team will bet on what to work on in the next cycle. This means looking into the catalogue of pitches and betting or voting on which ones should get priority for the next cycle.
As the product team goes through more cycles, their intuition on what is capable within a few weeks improves. This sharper intuition leads to predictability and the ability to have a steady cadence.
A process that is above all
Ego can play a significant role in the working environment. When not in balance, this can translate it team members that attribute themselves the right to change timelines or impose on others a different way of working that is favourable to them.
Shape Up fixes this by establishing a way of working that is above all.
The time constraint that Shape Up imposes acts as a forcing function, requiring team members to work with the end in mind and leave any ego out of the door.
Allocated time for learning new skills and general housekeeping
Between every cycle is a cool-down period. In our case, this was a week long. The cool-down is time for fixing bugs, refactoring code, or brushing up on new skills. Each team member can work during cool-down on things they want.
This shift of gears gives teams a valuable pause and the ability to do things that may often get neglected.
How to get started with Shape Up
- Define cycle length: Start by defining how long you want your cycles to be. Cycles are usually between 3 to 6 weeks; after every cycle comes a cool-down which is generally one week long.
- Keep a catalogue of pitches: A pitch has four essential ingredients: Problem, Appetite, Solution, Rabbit holes and No-gos. As ideas for improving the product arise, write them down as a pitch; this can be on Google docs or Notion. A pitch can start as a Notion page with one sentence and, over time, be given shape.
- Assemble a competent team: Teams in Shape Up are small. You will need a designer, a developer (or two) and someone that can do QA.
- Choose the features that will get worked on in the next cycle: During cool-down C-level team members come together and decide what gets worked on during the next cycle. This meeting is called the betting table.
- Repeat: Cycle after cycle, teams will better define appetite and keep the scope as small as possible.
How we implemented Shape Up at Teamscope
We used 3-week cycles and a 1-week cool-down. Although many teams work with 6-week cycles for us, three weeks felt light the right amount. This cadence also meant that per year we would ship twelve new features.
Each pitch was a page in Notion, and the extent of the pitch ranged from a one-line description to a fleshed-out pitch, including problem, appetite, solution, faqs, and UX/UI.
Inside the pitch, we would also keep track of the names of the users that had requested this feature; this allowed us to inform them once the feature was ready for beta testing or let them know that it would go in the next 3-week cycle.
At the start of the cycle, the first task was to write the whole pitch in the same language as our help documentation. We would do this in Notion, which would help us by the end of the cycle to have the help docs ready. On the day we shipped, all I needed to do was copy/paste in Webflow, which was our CMS and viola.
We tried as hard as possible never to interrupt a cycle, but if there were bugs in production that needed to get fixed, we would put the cycle on hold for a few hours and then get back to the cycle's plan. Context switches are expensive for productivity, so we tried our best to delay bug fixes for the cool-down week.
Creativity thrives within limitations; this is what makes Shape Up amazing. The strict time constraints of a cycle can feel uncomfortable at first. As teams learn to work within them, they get better at prioritising, honing in on their capabilities and deficiencies and making better use of our most valuable asset: time.
I'm convinced that teams that put in place Shape Up are on the right path towards a more zen working environment.
For us, it meant a steady cadence in our product development, the ability to ship twelve meaningful new features per year, and the valuable knowledge of what is achievable within the cycle's constraints with the personal and technical resources we had.