Search
Close this search box.

Weekly Tracker, Backlog, and Issue Log

When you first join a project, setting up trackers is not enough. You also need to understand why each tracker exists and how to keep it updated so it actually helps your team.

Weekly Tracker (Sprint Tracker)

  1. Purpose: Tracks what the team is committed to do this week. Think of it as the “current sprint.”
  2. When to update:
    1. By Sunday evening: Know what’s planned for the new week.
    2. By Monday: Sheet should already be up-to-date before the team meeting.
    3. Every day: Teammates update task status; you check and follow up.
  3. What to include:
    1. Task name
    2. Responsible person
    3. Priority (High, Medium, Low)
    4. Status (To Do, In Progress, Completed)
    5. Test Status (Tested, Kickback, Blocked, Not Tested)
    6. Description (with links like Figma if available)
    7. Blocker/Kickback comments
  4. Rules for maintaining:
    1. Team commits on Monday → those tasks stay on the Weekly Tracker for the week.
    2. Each teammate should have max 2 tasks in progress at once. More = divided focus.
      1. If someone has more than 2 in progress → sync with them or founder to reprioritize.
    3. If nobody updates by Tuesday, remind the group. Call out high-priority tasks.
    4. By Wednesday, you should already have 1–2 tasks to test. After testing, update the Test Status and log issues in the Issue Log if needed.
    5. Always confirm access on Monday (test links, environments).

👉 Tip: If you don’t know how to test something, call the developer. Ask them to walk you through it. You’re allowed to be “stupid” in your first month – just don’t ask the same thing more than twice.

Backlog

  1. Purpose: Holds tasks that are not for this week but may be done later. It’s the “parking lot” for future work.
  2. When to update:
    1. Move tasks here if they’re not selected during the Monday sprint planning meeting.
    2. Add new tasks here when they come up but aren’t urgent for this sprint.
  3. What to include:
    1. Task name
    2. Description (why it exists, what needs to be done)
    3. Priority (so you know which backlog items to consider first)
    4. Date added (to track how long it’s been waiting)
  4. Rules for maintaining:
    1. Backlog should not be a dumping ground. Always add enough context for tasks.
    2. Review backlog weekly with the founder or lead to pull tasks into the Weekly Tracker.
    3. Old tasks → check if still relevant or remove.

👉 Tip: Backlog helps you say no without forgetting. You’re not rejecting work, you’re just saying, “not this week.”

Issue Log

  1. Purpose: Tracks problems found during testing, meetings, or team updates. Keeps issues visible until resolved.
  2. When to update:
    1. Immediately after finding a problem during testing.
    2. Immediately a teammate makes/escalates a complaint 
    3. After meetings if issues are raised about the app or process.
  3. What to include:
    1. Issue description (what went wrong)
    2. Where it was found (meeting, exploratory test, developer update, etc.)
    3. Who reported it
    4. Priority (Critical, Major, Minor)
    5. Suggested fix (your idea – even if rough)
    6. Status (Open, In Progress, Resolved)
    7. Link to project/task in Monitora
  4. Rules for maintaining:
    1. Always log issues in the Issue Log and keep a note for yourself.
    2. Suggest fixes – but don’t make final decisions. Always discuss with founder or lead.
    3. If proposed fix still fits after discussion, document it clearly.
    4. Don’t let issues sit silently – follow up regularly until resolved.

👉 Tip: If you don’t log an issue, the team can forget it. If you don’t suggest a fix, you’re just complaining.

 

Your Tracker, Your Playground

These trackers aren’t just admin chores. They’re tools you own. Treat them like your personal lab:

  1. Keep them private if you want. Share them only if necessary.
  2. Mess around with permissions and see what happens when you change who can update what.
  3. Try out new ways of structuring tasks, statuses, or issue categories.
  4. Invent extra steps if they make sense to you (e.g., “Ready for Review” before “Completed”).

👉 Don’t wait for permission to improve these systems. This is your training ground. If you try something new and it works, great. If it doesn’t, you’ve learned something and you can goback to how things were before your experiment.

Facebook
Twitter
LinkedIn
WhatsApp
Email

Leave a Reply

Your email address will not be published. Required fields are marked *