ShapeUp
- Shaping and building have independent cycles.
- Time constraint as appetite for both shaping and building cycles.
- Integrate one slice from UI to backend during shaping.
- Making a bet for what to build and honoring it.
- Choose either base, precedent or unprecedent cycle length with cool-down.
- Break a project into independent scopes on a hill chart.
- Hammer a scope to break down must-haves from nice-to-haves.
Shaping is a work-in-progress ("WIP") option that could potentially change the status quo. This WIP must evolve into a well-shaped, risk-reduced, and thin-tailed timeline probability distributed option.
As an analogy, shaping is like a financial option that may either:
- Expire out-of-the-money - a WIP that is put on-the-shelf; or
- Callable in-the-money - a WIP that evolves into a well-shaped, risk-reduced, and thin-tailed return probability distributed option.
-
Backlogs are big time wasters, as the time spent on constantly reviewing, grooming and organizing old ideas prevent everyone from moving forward on the timely projects that really matter.
-
Bets are just a few well-shaped, risk-reduced options to review.
-
If we decide to bet on a pitch, it goes into the next cycle to build. Otherwise, we let it go, there is nothing we need to track or hold on to.
-
What if the time wasn't right? Anyone who wants to advocate for it again simply tracks it independently, without a central backlog, and then lobbies for it six weeks later.
-
Problem: The best problem definition consists of a single specific story that shows why the status quo doesn't work. Work on the shaping is kept private and not shared with the wider team until the commitment has been made to bet on it. This gives the shapers the option to either put WIP on-the-shelf or drop it when it's not work working out.
-
Appetite: Fixed time, variable scope. There is always a better solution. In terms of risk, well-shaped work looks like a thin-tailed probability distribution. There's a slight chance that it could take an extra week, but beyond that, the elements are defined and familiar enough that there's no reason it should drag on longer than that.
-
Solution: Giving a problem without a solution to the builder, means pushing research and exploration down to the wrong level, where the skill sets, time limit, and risk profile are all misaligned. Find the core elements, presented in a form that's easy for people to understand.
-
Rabbit holes: Address any potential entanglement in this concept to reduce the risk of fat-tail timeline.
-
No gos: Anything we are not doing in this concept should be explicitly stated as this will reduce the risk of a fat-tail timeline.
When we shape the work, we need to do it at the right level of abstraction.
- Wireframes are too concrete.
- Words are too abstract.
Shaping is to sketch a rouch concept, leaving many details out.
- Handdrawn-rough
- 5x why-solved
- Variable-scoped
- Time-constrained ("appetite")
- Private
Once we think we've shaped it enough to potentially bet on, we package it with a formal write-up called a pitch.
- Places
- Affordances
- Connection
A place is a thing that you can navigate to, such as menu, dialog etc. Write a word above a line for place, or draw a box.
An affordance is a thing user can act on, like a field or button. Write word under the line to indicate they can be found at that place.
A connection shows how an affordance takes the user from place to place. Draw an arrow from an affordance to a place.
The pitch summarizes the problem, constraints, solution, rabbit holes, and limitations. The pitch goes to the betting table for consideration.
Before each six-week cycle, we hold a betting table during cool-down where stakeholders decide what to do in the next cycle.
Some companies use two-week cycles ("sprints"). We learned that two weeks is too short to get anything meaningful done.
Within the six-week cycle, you can breakdown the weeks to smaller periods that you can assign to each scope of the project.
If we were to run six-week cycles back to back, there wouldn't be anytime to breathe and think about what's next. Therefore, after each six-week cycle, we schedule two weeks for cooldown.
Our base case is to run six-week cycle with two-week cooldown. Unprecendent case is 12-week cycle with 4-week cooldown.
For a shorter project, use a precedent case of 3-week cycle with a one-week cooldown.
The vast majority of bugs can wait six weeks or longer, and many don't even need to be fixed. You can't ship anything new if you have to fix the whole world first.
Since the team was given a project, not tasks, they need to come up with the tasks themselves. Here we note the important difference between tasks we think we need to do and tasks we discover we need to do.
The way to really figure out what needs to be done is to start doing real work.
Scopes are bigger than tasks but much smaller than the overall project. The scopes reflect meaningful parts of a project that can be completed independently and in a short period of time - a few days or less.
There are almost always a couple of things that don't fit into a scope. We allow ourselves a "chowder" list for loose tasks that don't fit anywhere.
New tasks constantly come up as you get deeper into a problem. Mark nice-to haes with a tilde ("~") in front.
The team could start with UI, but until it's wired to a backend, nothing does anything.
Same with the backend. A lot of tasks could be checked off, but without any UI what can you do with it?
What we want is to pick of one slice of the project to integrate. When it's done, anyone can click through the interaction and see if the feature does what it should.
In real life, tasks are discovered by getting involved in the problem. That means to-do lists actually grow as the team makes progress.
We came up with a way to see the status of the progress without counting tasks and without numerical estimates. We do that by shifting the focus from what's done or not done to what's unknown and what's solved.
The scope gives us the language for the project ("Locate", "Reply") and the hill describes the status of each scope ("uphill", "downhill").
For managers, the ability to compare past states is the killer feature. A dot that doesn't move is effectively a raised hand.
Sometimes probing into a stuck scope reveals that it isn't stuck at all. The solution may be to break the scope into smaller scopes.
In addition to seeing where the work stands, we can use a hill chart to sequence the work - which problems to solve in which order.
