Heartbeats are our invented term to describe what is sometimes called a sprint, or a spike. Both of those terms sound scary, and this is how we want to operate on a constant and sustainable basis, so we picked a softer term.
The key idea behind a hearbeat is that a two-week period is a good sized unit of time to make real progress on a well-defined chunk of work, especially if people have a shared understanding of how the planning, execution, milestoning, checking in, etc. all happen. Hopefully this FAQ helps people ramp up with that knowledge.
A heartbeat is a unit of time. During a given heartbeat, we'll have multiple parallel initiatives. Each of those initiatives has a set of people involved, and an "owner", whose job is to see to the successful completion of that initiative. That is primarily a project coordination and project management role, but anyone can be an owner (assuming they have the skills, interest and commitment).
- What initiatives are currently under way?
- What initiatives are planned?
- How do I affect the plan?
- What is a "meta" issue?
- Explain P1 and P2?
- How do priorities and scheduling get decided?
- What is the role of an initiative owner?
- What is the role of an decision lead?
- What is the role of an lead designer? Other designers?
- What is the role of an lead dev? Other devs?
- What is the role of an quality lead?
Each initiative is associated with a meta issue, in the plan repo. We have a fancy page on build.webmaker.org/now that displays all of the issues currently under way.
Using the same method, you can see the set of issues currently on deck for the next hearbeat as well as longer term view
To add an issue to the plan repo, please use the purpose-built form that will ask specific questions designed to elicit answers that can help the planning group understand scope, urgency, impact, etc. Feel free to talk to your favorite project manager to do some prep work. Or just file the issue and we'll get back to you with questions as necessary. If something is urgent (can't wait until the end of the current hearbeat to be scheduled), get in touch with a project manager and bring it up in person.
We refer to the issues in the plan repo as meta issues because their primary purpose is to help us understand the need and resource and schedule, they're not where the work or work-related decisions happen. In general, each initiative will have a set of issues that live in a project-specific repository, with a longer time horizon, much more granular issue management, etc.
P1 initiatives those that the planning team and the initiative participants commit to get done in a heartbeat (we may be overconfident at times, but our goal is to deliver on those close to 100% of the time). P2 initiatives are those that we'd like to see progress on, but they're explicitly not as critical as the P1 initiatives. We'd like to be able to complete those at least 50% of the time, but we make no promises.
On the first Monday, the planning group meets and discusses the plan as a group. We try to all understand the high level reason for each proposed initative, schedule constraints, resource needs, etc. Critically, we try to understand how that initiative fits within the plan and moves us closer to both quarterly and yearly goals. The better prepared the planning group is with this process, the more intelligently that prioritization will happen. This means that ideally there's been pre-work on the meta issue to surface important criteria like rough scope, external requirements, dependencies, etc. The planning group is a cooperative body, each member must committ to advancing the overall organization's goals and not just to advocate for their departmental view. If the planning group's priorities feel wrong, bring it up with tps or ops