Drum Project Management

Drum creates a weekly work beat that leads autonomy with rhythm.

Drum is a project management framework used to manage and complete complex projects. It emphasizes teamwork, transparency, and autonomy to complete deliverables on-time.

Drum is similar to Scrum, but with a weekly rhythm.

Each person/team picks weekly tasks, and progress in a short Friday Celebration

Here's a brief overview of Drum:


Drum has three main roles:

  • Product Owner: Broadcasts the Vision, looks out for stakeholders and is responsible for defining and prioritizing the product backlog + sprints.

  • Drum Master: Turns the Product Backlog into sprints and sprints into Weekly Plans at Monday meetings, and celebrates work completed in Friday partys. Ensures all follow the Drum process.

  • Member/Teams: Responsible for executing weekly plans + reporting progress each day + week, and passing off deliverables to the rest of the team. A team is together for one sprint

Moving Parts of Drum

Drum has Five main parts:

  • User Stories - Determine what is done, communicated in three main elements:

    • As a [role]: Who will benefit.

    • I want [feature/functionality]: What the beneficiary desires.

    • So that [benefit/value]: Exactly why they want this.

  • Product Backlog: A prioritized list of conquerable deliverables that fulfill user stories.

  • Sprints: A sprint is one deadlined release of related deliverables from the product backlog that the team is currently focusing on that fulfills a user story.

  • Weekly Plan: Is the work each member/team agrees on Monday to complete by Friday 4:44pm to complete or progress a sprint.

  • Deliverable: The finished product/feature/advancement marking the end of a sprint, completing or progressing a user story. A deliverable must be reviewed on Friday by the Drum Major.

How Things Get Done: Sprints + Weekly Plans

Flow Overview

User Story >> 1 or more Product Backlogs >> 1 or more Sprint to complete a Product backlog entry >> Team pick parts of sprint they'll work on, becoming the Weekly Plan

Sprints are defined as a list of components, and steps to complete a component

- Component 1 of deliverable
	- step 1
	- step 3
- Component 2
- Component 3

On Monday, the drum major talks with team to see if the entire sprint(s) can go on the weekly plan, or if not, what parts they can commit to do this week.

Members/teams have control over what they commit to, and are asked, not told what they will complete this week

Once they commit, they are responsible to have the work done by Friday at 5pm, or they may have to play catch up to get back with the team.

Sprints have One Deliverable that completes (part of) a Product Backlog based on a User Story.

At the end of each week, each member shares in a weekly meeting what they have done, explaining on Zoom screenshare + linking in the Team Product Log (Private to team members)

At the end of each sprint, the work is presented to the entire team, stakeholders may be invited, and the meeting may be recorded to be shared.

Drum Ceremonies

  • Weekly Planning: The team plans the work for the upcoming sprint, selects items from the product backlog to put on the, and defines the sprint goal. (11am Mondays)

  • Daily Standups: A daily meeting where team members share their progress, discuss challenges, and align on the work to be done. (9:45-10am)

    • What you did yesterday

    • What you will do today

    • Anything blocking your progress / Opportunity to be heard, helped or hugged

  • Friday Celebration: The team displays what they created and are celebrated. This

  • Sprint Retrospective: Demonstrates the deliverable to team + invited stakeholders, gathers feedback, and reviews progress. The team reflects on the sprint, identifies areas for improvement, and agrees on actions to improve processes.


If it isn't delivered to all team members, it didn't happen.

If you did work, but didn't provide a link to the work everyone can access after the meeting, you didn't do it.

If you shared a link to your work in Team Product Log, below the deliverable, you did it.

If it isn't part of a user story, it won't enter the Product Backlog

If you have an idea you want to be built into Tetra, you must propose it to the Product Owner, who can decide to add it as a user story, or as a backlog entry related to an existing.

If it isn't in the Weekly Plan, it's not time to work on it..

..unless you've done everything in the weekly plan. Then;

  1. if you need someone else to clear something blocking you, bring it up in the daily meeting

  2. if it's not on the current sprint, find something in the current sprint

  3. if the current sprint is also done, look at the product log and see what you'd like to start planning / working on and start in silence. Share progress in Friday meeting, then in Monday meeting you may request more time to work on it.

If you've completed everything you can possibly think to do, you can ask in the group if anyone needs help, or talk to the Drum Major.

Last updated