The “Shape up” approach
The “Shape-up” timeline
If you have an established product, then you’re probably less concerned about big release plans. Instead, your priority will be to enhance your product regularly. For such situations, I’m a big fan of Ryan Singer’s “Shape up” approach. This approach has no estimates. No velocity tracking. Not even a backlog. Ryan’s written a book on the topic that goes into details; but let me explain the approach at a high level.
Anyone can come up with ideas to improve the product. Before any of these ideas go into development, a group of people “shape up” the work.
The product of the shaping process is a pitch document. This document summarises the problem, the constraints, the solution, and the go/ no-go areas. It doesn’t have wireframes or mock-ups. No stories, or architectural diagrams either. Designers and developers can figure out those details if they end up working on the problem. The document uses fat marker sketches and box-and-arrow diagrams to illustrate the potential solution.
Not all pitches make it to development. Each cycle, all shaped pitches go to a “betting table”. This is where a team of people who’re responsible to make decisions about a product decide which pitches to bet on. By betting on a pitch, they commit a team for six weeks and solve that problem. Why six weeks? Singer says that it’s long enough for a team of two or three people to finish substantial work and short enough to plan for.
A key feature of the shaping process is the notion of a “capped downside”. The shaping team must be confident that a development team can execute the idea in six weeks. The six-week time-box is also a circuit breaker. If the development team can’t ship in 6-weeks, then it represents a shaping problem. Work stops and the idea goes back into shaping.
The corollary to the capped downside is that development teams get uninterrupted time to work on their problem. They also have the freedom and autonomy to “hammer scope”; i.e., focus only on the absolute must-haves to solve the problem in their six-week cycle.
Development teams divide their six-week project into broad scopes and constituent tasks. They communicate status asynchronously and transparently using hill charts. On the left-hand side of the chart are scopes where you’re still figuring out what to do. On the right you’re getting things done. One view with click throughs to detail can show you where the team is at. When you compare different states of the chart you get a sense of progress.
Shape up follows a two-track approach. While development teams hammer away at their respective problems, the shaping team creates pitches to bring to the betting table.
At the end of six weeks, the dev teams ship their software into the wild and get two weeks to cool-down. This is time to not just get a breather but to also tie up some loose ends, maybe make some minor bug fixes.
This is also the time when the shaping team brings pitches to the betting table. Every eight weeks the cycle repeats itself.
I encourage you to pick up Ryan’s book and read it cover to cover. If you’re responsible for an established product, you’ll find that this approach allows you to facilitate autonomous teams. At the same time, you forecast only a few weeks at a time, to keep your product and your ideas fresh.