The below backlog process for product managers gives a workflow to be used when focusing on value to a customer. It’s written to help give insight into an efficient product (and therefore engineering) workflow.
Creating an organized, prioritized backlog of stories is one of the most important artifacts of a successful product manager. This is no easy task. Below is an adapted methodology that the product manager at my startup used, and I found myself using it with every team I’ve led.
It’s meant to be a starting point so it may need some adjustments to your current workflow. Keep in mind, some of the processes are purposefully not flexible, they require discipline and focus. It may time to acquire that in a team but it is worth the reward.
Although written specifically for Tracker, it can be adapted for other product management tools.
Story added into Tracker: The acceptance criteria are agreed upon by design and engineering and documented in Tracker as a user story and acceptance criteria written by the PM or VPE. All assets should be attached and the epics tagged.
Feature or bug story is placed in backlog in order of priority as decided upon by engineering and design. There is no concept of low/medium/high only what gets done next. Chores are prioritized by engineering.
Feature stories are pointed by the PM with the help of engineering and/or VPE. Stories with large points suggest that it’s estimates are not predictable and those stories should be broken into smaller more predictable values. This allows engineering to relay to business “how much time will something take” instead of “how hard is this to do”. The difficulty is a value that requires engineering context which design and business do not have. Time is a value that requires a context all teams have. Point estimates:
|0||simple replace of an image, no coding or engineering|
|1||engineering has done >2 times before|
|2||engineering done it before or you have something you can reference|
|4||engineering needs to research beforehand|
|8||engineering has no idea what to do - needs to be broken down into smaller tasks|
An assignment of a story to an engineer/designer should happen sparingly. If there is an engineer who has a specific skill set requiring them to be the only one to complete a story, they can be assigned. In most cases, a story should not be assigned to an engineer.
As always, use your judgment and adjust accordingly. Know-how and when to adjust can be an art form but don’t let that be demotivating. Keep the customer in mind and that should give you the intuition needed.