You're reading the page 2 of the Product Development Handbook.
**People and Roles
Capture Context Define a Feature Prioritize → Build Measure
Every ticket in the developer board should be able to be traced back to it's source. Briefs and Feature specs are the prep work that is required to get stories or tickets ready to go into the dev backlog. Treat briefs and features specs as a wiki that gives context to the tickets that are in progress.
A technical backlog is a place where your team can either thrive, share knowledge and instantly understand what work is the most important. Or it can obfuscate reality and create conflict within the team.
Anyone should be able to grab any ticket from the Developer Board and within about 2 minutes be able figure out:
Use visual boards and tickets to represent work to share status with any interested party. Tickets are a unit of work they can be a task, gherkin spec, user story, integration, UI fix, or any piece of work that the team does. The point of a ticket is that they are visible, trackable, relationship-based, trackable, and share context. You can see who is working on what and updates on their work.
A well-designed developer board allows any team member to look at the board and understand the status of all work on the go. It helps build trust within the team through accountability. Visualised boards can also be set up to chow remaining work and communicate timelines without estimations.
To read more about displaying progress, check out this book → Making Work Visible: Exposing Time Theft to Optimize Work & Flow
Who owns the work: Tech Lead Who's involved: Software developers, Product Manager
The product manager defines the 'What', and the Developer Lead defines the 'How'. When a Feature Spec is ready enough for the dev team to start building it, that feature spec is prioritised against all other Feature Spec by the product manager. However, as that Feature Spec gets scoped into the backlog, the Developer Lead is responsible for managing how that feature will be built.
They can choose to map each ticket to a spec, a user story or add additional tasks such as reducing technical debt. The Tech Lead works with the dev team to manage who is working on what ticket and when.