Like most agile teams, we divide up the roles on our team into team members, scrum masters, product owners, and managers. We treat some of those roles differently than a traditional engineer-centric scrum team:
- We combine the role of team manager and product owner into one person.
- Each writer is responsible for "liaisonships" where they track work across a particular product or feature and bring in appropriate tickets.
- We don't expect scrum masters to clear blockers (that's a manager's job), and scrum mastering is not a full-time job.
- We divide the team further into two squads, each with its own team members, scrum master, and product owners.
Team members are responsible for:
- Doing writing work.
- Improving the team's processes and how we work together.
- Writing stories for sprints in accordance with their work (via laisionships, SME conversations, hero work, etc.). The person who nominates a story will also present it during sprint planning. See Ticket best practices for tips on writing a good ticket.
- Managing one or more Liaisonships.
Each squad has a scrum master. The scrum master is not responsible for unblocking stories or communicating with stakeholders on behalf of the team (this work belongs to individual writers and their manager). We believe this lets the business have a single point of accountability (managers) for decisions, and ensures scrum masters have hands-on experience of what it's like to be a writer.
Instead, for us the scrum master is a custodian of the sprint process and the MC for sprint meetings.
- In backlog grooming: The scrum master handles the mechanics of talking through each ticket and facilitating conversations about story quality.
- In sprint planning: The scrum master leads conversation, tracks discussion time, adds point values to stories, and organizes/ranks sprint candidates in real time. They don't present the stories, though—stories should be introduced by the person who nominated the story for the sprint.
- In retros: The scrum master facilitates the discussion, captures action items, and takes notes.
Tech Docs managers (and product owner)
Each squad has a manager---or perhaps you could say each manager has a squad. Either way, the manager's role is to prioritize the right work for the business, maintain a healthy workload, and help escalate when a writer needs help.
The managers are responsible for understanding how our entire body of work serves the organization, and making informed decisions about our velocity and workload. The manager engages with other teams to know which features may be coming into the pipeline and has a general understanding of work that may be in future sprints. This lets them make final priority decisions for the team and be accountable to the business for those tradeoffs.
The manager is also responsible for assigning liaisonships and ensuring we're covering the portfolio. They'll also work with other teams to unblock writers when needed.
Our key internal stakeholders include PMs, engineers, designers, and executives. Writers work with the stakeholders to know when new work is coming, and to communicate documentation needs/timelines.
We should ensure our stakeholders know that we work in two week sprints, so that they can give us adequate lead time and get their documentation needs met.
We welcome thoughts or questions on our handbook! The easiest way to get in touch is to file a GitHub issue.