Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. https://basecamp.com/shapeup/0.3-chapter-01#six-week-cycles
fixed time, variable scope
There’s always a better solution. The question is, if we only care enough to spend two weeks on this now, how does this specific solution look? https://basecamp.com/shapeup/1.5-chapter-06#ingredient-2-appetite
Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? https://basecamp.com/shapeup/0.3-chapter-01#shaping-the-work
..., we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. https://basecamp.com/shapeup/0.3-chapter-01#making-teams-responsible
When design leaders go straight to wireframes or high-fidelity mockups, they define too much detail too early. This leaves designers no room for creativity. https://basecamp.com/shapeup/1.1-chapter-02#wireframes-are-too-concrete
When a project is defined in a few words, nobody knows what it means. “Build a calendar view” or “add group notifications” sound sensible, but what exactly do they entail? Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out. https://basecamp.com/shapeup/1.1-chapter-02#words-are-too-abstract
The shaped concept is an interaction design viewed from the user’s perspective. It defines what the feature does, how it works, and where it fits into existing flows.
It’s rough. Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. https://basecamp.com/shapeup/1.1-chapter-02#property-1-its-rough
It’s solved. All the main elements of the solution are there at the macro level and they connect together. https://basecamp.com/shapeup/1.1-chapter-02#property-2-its-solved
It’s bounded. ...shaped work indicates what not to do. It tells the team where to stop. https://basecamp.com/shapeup/1.1-chapter-02#property-3-its-bounded
https://basecamp.com/shapeup/1.1-chapter-02#steps-to-shaping
- Set boundaries.
- Rough out the elements.
- Address risks and rabbit holes.
- Write the pitch.
When you pull someone away for one day to fix a bug or help a different team, you don’t just lose a day. You lose the momentum they built up and the time it will take to gain it back. Losing the wrong hour can kill a day. Losing a day can kill a week. https://basecamp.com/shapeup/2.2-chapter-08#uninterrupted-time
The mere fact that something is a bug does not give us an excuse to interrupt ourselves or other people. All software has bugs. The question is: how severe are they? If we’re in a real crisis—data is being lost, the app is grinding to a halt, or a huge swath of customers are seeing the wrong thing—then we’ll drop everything to fix it. But crises are rare. The vast majority of bugs can wait six weeks or longer, and many don’t even need to be fixed. If we tried to eliminate every bug, we’d never be done. You can’t ship anything new if you have to fix the whole world first. https://basecamp.com/shapeup/2.2-chapter-08#what-about-bugs
https://basecamp.com/shapeup/3.1-chapter-10#assign-projects-not-tasks
The way to really figure out what needs to be done is to start doing real work. https://basecamp.com/shapeup/3.1-chapter-10#imagined-vs-discovered-tasks
...aim to make something tangible and demoable early—in the first week or so. That requires integrating vertically on one small piece of the project instead of chipping away at the horizontal layers. https://basecamp.com/shapeup/3.2-chapter-11
it should be core, it should be small, it should be novel https://basecamp.com/shapeup/3.2-chapter-11#start-in-the-middle
..., we came up with a way to see the status of the project 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. To enable this shift, we use the metaphor of the hill. https://basecamp.com/shapeup/3.4-chapter-13#estimates-dont-show-uncertainty
QA can limit their attention to edge cases because the designers and programmers take responsibility for the basic quality of their work. Programmers write their own tests, and the team works together to ensure the project does what it should according to what was shaped. https://basecamp.com/shapeup/3.5-chapter-14#qa-is-for-the-edges
We treat code review the same way. The team can ship without waiting for a code review. There’s no formal check-point. But code review makes things better, so if there’s time and it makes sense, someone senior may look at the code and give feedback. It’s more about taking advantage of a teaching opportunity than creating a step in our process that must happen every time.