Ceo, David and Ryan make the decision about what makes it into a cycle. What makes the cut depends on many variables. If something doesn't make it in, it can be considered again in about a month and a half. The good news: in six weeks we can start all over again with another batch of work.

How do you decide which projects to take on?

Once the cycle has been defined, and work grouped into Big Batch and Small Batch projects, I write up an announcement and post it to the “Building BC3” project inside Basecamp. The Building BC3 project is the master project for high-level Basecamp-related product work. It’s where we talk big picture items, share pitches, discuss ideas, schedule the cycles, etc.

How does the cycle get announced?

There are two people on our QA team. They roam between ongoing projects, invited in by the teams when they want something checked and double-checked. We’ve found that the earlier they’re involved the better. QA fits into the six-week time frame too, so nothing busts a deadline like a pile of last-minute QA findings. That’s why we don’t wait until the end to start QA. Most of the time at least.&nbsp;

How does QA work?

Roughly every six weeks we start a new cycle of product work. Each six-week work cycle contains two types of projects:&nbsp;<ul><li>Big Batch projects are big features or stuff that’s probably going to take up the full six weeks to get doneWe typically take on between 4 and 8 small batch projects.</li><li>Small Batch projects are smaller things, tweaks, minor adjustments, and easily adds that should take anywhere from a day to two weeks to complete.</li></ul>

We work in six week cycles

If we take on two big batch projects during a cycle, we’d have one team working on one of the projects and another team working on the other. A team is two or three people, depending on the type of work. Either one programmer and one designer, or two Programmers and one designer. That’s it. No teams of four, five, six.

Who does the work?

No. We don’t measure efficiency, compare actuals vs. estimates. We have six weeks to get something done. However, a team deciding to get it done during that time is up to them.What is important is that we don’t run-up to the end and figure out we’re out of time. We’re always looking at what’s done, what’s left, and how much time remains.

Do we track time?

We don’t have distinct time set aside to come up with ideas. There’s not a distinct set of people who come up with all the ideas. Ideas come from all over and are offered up any time. They come from us, they come from customers. Ideas are always in motion. There’s always a bubbling ocean of ideas. Every once in a while a bubble floats out of the ocean and lands on the shore. That’s when we begin to take a closer look.&nbsp;

Where do ideas come from?

Why don’t we pitch in person? For a few reasons:&nbsp;<ul><li>The person who’s making the pitch can’t be interrupted.</li><li>Further, we believe writing things out makes you consider them at a deeper level.&nbsp;</li><li>Real-time communication forces synchronization of schedules.</li><li>All feedback and follow up questions are automatically attached to the original post. This keeps all communication about the pitch centralized in one place.</li></ul>

Pitching an idea

The designer on the team leads the project, but there’s a very close working relationship between designer and programmer (s) they work together on everything. When everything’s in one place, everyone knows where things are, where things stand, etc.

Do we have dedicated project managers?

The secret to making this possible is something we call scope hammering.Scope hammering takes the chisel to the big block of marble and figuring out how to Sculpt, nip, and tuck a feature into the best Six-Week version possible. Before any project is included in a cycle, we’ve already figured out what the six-week version is. It has to happen before the work is slated to be done by a team.

Six weeks… What if something’s so huge it’s going to take longer?

“How do you guys actually work? How do you choose what to do? How big are your teams? How do you structure the work itself” are questions I get all the time. I’ve been sharing the details in small…