The Product Backlog is a new working process being used by developers at Resonate.
Many tasks → a handful of Milestones → one Goal.
If you have an idea for a task that would move us toward a Milestone, add it under Potential. Do not add a priority (high, medium, low) to a Potential task. Task prioritization is done by informal agreement of @maintainers, developers, and guests at weekly dev meetings.
If you are aware of a prioritized task which isn’t yet on the Product Backlog, add it under Prioritized.
Assign yourself to tasks you are doing or coordinating.
If tracking subtasks elsewhere, represent that workspace as a card, label the card External, and add a URL to it. Don’t write subtasks on a card labeled External.
Move task cards on the Product Backlog using your own judgment.
Represent the current Product Goal with a card labeled Goal.
Represent each Milestone toward the Product Goal with a card labeled Milestone.
A Task should be represented by its own card, rather than being added within a Goal or Milestone card.
A Subtasks checklist can be added within a Task card. Since a Task card can only be assigned to one person, the expectation is that all Subtasks within a Task card will be done by that person.
A Criteria checklist can be added within a Milestone or Goal card. Criteria are not Subtasks, but instead define what criteria must be met in order for a Milestone or Goal to be considered complete.
I see you subtweeting me combining multiple tickets into one as a checklist
Here’s my reasoning: the current technology we use has no real way of grouping tickets or marking them as related. It doesn’t make a distinction between Epics and other cards. Ideally, if we could filter them that would be great (either by person assigned or by epic), but currently the list is massive and that doesn’t work. A massive list like that is hard to work with.
On top of that the current goal is still in the definition-of-scope stages. Once it’s more defined and we have a better understanding of what the tasks are that will be involved in it, I think we’ll be able to break out specific tasks and move them forward. Once a task starts getting worked on, I agree, it should be moved into its own card.
So I’d propose the following change to your lists above:
Goals can act as a space where tasks related to the goal are articulated and gathered, before the actual work and scope of those tasks gets fleshed out and specified. Once a task is fully articulated and ready to be assigned to someone and work on, it should be turned into a card representing the task.
I’m catching up on the call recording now so I hear the reasoning of “for brainstorming, let’s see related tasks in one place before breaking them out into cards”. Makes sense to me!
I think that a Criteria checklist would help with this too. Rather than trying to anticipate all tasks toward the Goal, a Criteria checklist on a Goal or Milestone card would refine agreement about what the destination will look like. Y/N criteria like “a dev can spin up the whole stack with one click” (or however on earth that should be worded lol)
