Collaborator Role Guide
Collaborators do the work. They create items, move them through the workflow, write estimates, and drive milestones to completion. Most of the people on a development team should be Collaborators.
The role is designed around a simple question the interface answers every day: what should I work on next? You do not need to figure this out yourself. The standup view surfaces it. The backlog is ordered by priority. Highlights tell you when something needs attention before you pull new work.
This guide covers how Collaborators operate within the process. For the full permissions matrix, see User Roles & Permissions.
Responsibilities
Creating and managing items. Collaborators create work items when they discover scope that is not yet captured: bugs found during development, technical tasks that emerge from implementation, subtasks needed to complete a larger item. Items should be concrete enough to estimate and small enough to finish within a day or two.
Moving items through the workflow. The status workflow is a communication tool as much as a tracking tool. When you start working on something, mark it Started. When your work is done, mark it Finished. When it has been shipped or handed off, mark it Delivered. Each transition tells the team something real.
Adding estimates. Collaborators add story point estimates to items. Estimation is not a precision exercise. It is a shared calibration: the team agreeing on relative size so velocity calculations mean something. An item with no estimate cannot contribute to the forecast.
Surfacing blockers. When something is preventing you from making progress, flag it immediately. Use the Blocked highlight and add a note explaining what is in the way. A blocker left unflagged for two days is two days of invisible delay. The Project Leader or Owner can only help if they know.
Participating in meetings. Collaborators attend milestone planning, standups, and retrospectives. In milestone planning, they provide the estimates that make the backlog credible. In standups, they surface what they finished, what they are working on, and what is blocking them. In retrospectives, they identify what is actually slowing the team down.
The Item Status Workflow
Items move through a defined sequence. Each status has a concrete meaning.
| Status | Meaning |
|---|---|
| NotStarted | In the backlog. Not yet being worked. |
| Started | Actively in progress. You are working on this now. |
| Finished | Your work is complete. Ready for review or handoff. |
| Delivered | Shipped to production or handed to the stakeholder who asked for it. |
| Accepted | Verified by the Owner or Project Leader. Meets requirements. |
| Rejected | Reviewed and does not meet requirements. Needs rework. |
The distinction between Finished and Delivered matters. Finished means the code is written and tested. Delivered means it is actually in the hands of whoever needs it. Skipping Delivered because "it will go out in the next deploy" is how teams lose track of what has and has not shipped.
Accepted is not something Collaborators set. The Owner or Project Leader marks Accepted after verifying the work.
Meeting Participation
| Ceremony | Collaborator's Role |
|---|---|
| Standup | Core participant. Reports blockers, in-progress work, what finishes today, what starts today. |
| Milestone Planning | Core participant. Proposes items, provides estimates, challenges scope assumptions. |
| Retrospective | Core participant. Identifies process friction and improvement opportunities. |
| Alignment Meeting | Attends, does not vote. Can raise blockers for stakeholder visibility. |
| Roadmap Planning | Optional. Attends when there is technical input to provide on milestone scope or sequencing. |
Daily Workflow
The standup view is the starting point for the day. It organizes your work by what matters now, not by creation date or alphabetical order.
Open the standup view. This surfaces your current items organized by status. If you have items in Started, those come first. Items with highlights come before everything else.
Handle highlights. Before pulling new work, clear your highlights. If you have items marked Blocked, do something about the blocker: add more detail, ping the person who can resolve it, or escalate to the Project Leader. If you have a Question highlight on an item, get the answer before proceeding.
Continue active work. If you have items in Started, continue them. Starting a new item before finishing the current one increases WIP and degrades forecast accuracy. Finish what you started.
Pull the next item. When your current item is finished and moved to the right status, pull the next highest-priority item from the backlog. The priority order is set by the Project Leader and Owner. You do not need to decide what is most important. Pick the item at the top.
Update status when done. Mark items Finished when your work is complete. If the item is going straight to production, mark it Delivered. Do not let items sit in Started after you have stopped working on them. Stale statuses mislead the team and corrupt velocity metrics.
Using Highlights
Highlights are signals to the team. Use them when something needs attention beyond normal status updates.
| Highlight | When to use |
|---|---|
| Blocked | Something is preventing you from making progress. Dependency not ready, decision not made, environment broken. |
| Question | You need clarification before you can proceed. Unclear requirements, conflicting specs, ambiguous acceptance criteria. |
| Discussion | The item raises something the team needs to talk through. Scope change discovered during implementation, technical approach decision. |
Set the highlight and add a comment explaining the situation. Do not leave a highlight without context. "Blocked" with no explanation is not actionable.
Estimation
Collaborators add story point estimates using a Fibonacci scale: 1, 2, 3, 5, 8.
Estimates are relative. A 3-point item is not three hours of work. It is an item the team considers roughly twice the size of a 1-point item. The absolute numbers do not matter as long as the team applies them consistently.
Rough calibration:
| Points | What it typically means |
|---|---|
| 1 | Trivial change. Single file, obvious implementation, no risk. |
| 2 | Small but real work. Clear scope, low risk. |
| 3 | Typical feature. Multiple components, some decisions to make. |
| 5 | Large feature. Several unknowns, meaningful implementation time. |
| 8 | Very large. Consider splitting before starting. |
If an item is an 8, try to split it. Items that are too large to complete in a few days are harder to track, harder to estimate accurately, and harder to unblock if something goes wrong.
Unestimated items do not count in velocity calculations. An unestimated backlog produces unreliable forecasts. Estimate items during planning, and add estimates to new items as you create them.
When to Use This Role
The Collaborator role fits anyone actively doing the work: developers, designers, QA engineers, technical writers, anyone creating deliverables. If your primary contribution is building things rather than setting direction or observing progress, Collaborator is the right role.
Collaborators who consistently demonstrate good judgment about priorities and technical decisions are good candidates for the Project Leader role.
How GoalPath Supports This Role
The Collaborator interface is designed around one problem: knowing what to work on next. The standup view organizes your items so the answer is always visible. Highlights surface what needs attention before you can pull new work. The backlog is ordered so you never need to decide priorities yourself.
GoalPath also provides the data that makes estimates meaningful. Velocity tracking shows how the team's actuals compare to estimates over time, which helps calibrate future estimates. The forecast shows the real impact of finishing items quickly or getting blocked, which makes day-to-day status updates feel connected to something that matters.