Issue driven project management (IDPM) guidelines

IDPM is an agile project management process designed to support up to a dozen developers creating software up to approximately 500K LOC with “web app” grade quality. Other project management approaches will be better for larger teams, larger code bases, or more stringent (i.e. life-critical) quality requirements.

Here are a set of guidelines which implement IDPM.

Meet twice a week to manage project.

For IDPM to work effectively, your team should meet together approximately twice a week to review progress and update the upcoming set of tasks to complete. While online meetings can work, face-to-face is generally quicker and results in better coordination.

Divide work into 72 hour tasks.

For multiple people to work together effectively, you must figure out a way to decompose the work into small tasks that can be worked on independently. As a guideline, each task should take approximately three days to accomplish. If a task appears to take longer than that, then decompose it into subtasks. If a task takes only a few minutes to accomplish, then just do it and don’t bother to document it.

You do not have to figure out all the tasks before starting work. At any time, you only need to have the next 3-4 days of tasks precisely specified, since you will meet again within 3 days to revise the task list.

Document each task as a GitHub issue and assign it a single owner.

Specify each task as a GitHub issue, and make one team member the owner of that task. While multiple people might participate in completing a task, you should always specify a single person as having ultimate responsibility for completing it.

Perform work associated with each task in its own branch.

To minimize coordination conflicts, create a branch for each task (i.e. GitHub issue). Use the issue number to name the branch to make the association explicit.

For example, if a task is “Put system under CI”, and it’s issue #15, then the branch in which this is accomplished might be named “issue-15”.

Merge the branch back into master when the task is accomplished. If, after merging, you realize the task isn’t yet finished, just continue work in that branch and merge again.

Group tasks into 7-10 day milestones constituting “deliverables”.

Every 7-10 days, your team should “deliver” something concrete regarding the project. To support this, organize development into a sequence of Milestones occuring every 7-10 days.

Every task (i.e. GitHub issue) will be assigned to exactly one (GitHub) Milestone. Choose which tasks to assign to which milestone in order to achieve a concrete deliverable every 7-10 days.

Every team member should have at least 2 Issues in the currently active Milestone.

To ensure that everyone always has something to do, assign at least two issues to each person. That way, if they finish what they are working on before the next meeting, they have another task they can switch to immediately.

Create a GitHub Project to manage progress within a Milestone.

For each Milestone, create a GitHub Project Board specifying the “Automated Kanban” template. This will result in a Board with three columns: To Do, In Progress, Done.

At the start of the Milestone, add every issue to the To Do column. Assign issues to team members during the meeting. There should be at least two tasks per team member, each task ideally taking 2-3 days to accomplish.

As team members take on a task, they should:

When team members complete a task, they should:

Use GitHub Project Board automation to simplify task management

The GitHub Project Board “Automated Kanban” template can simplify project board management in two ways:

  1. When a new issue is created, it is automatically moved to the To Do column.
  2. When an issue is closed, it is automatically moved to the Done column.

More details on project board automation can be found at

All team members have a GitHub profile photo

Understanding who is assigned an issue is significantly easier when every team member has a Github profile photo. Otherwise, a randomly generated avatar is associated with the issue owner in the project board. For this class, please go to your profile page in GitHub and provide a headshot for your profile photo.