Our team uses a fairly "by the book" agile-scrum implementation, with the understanding that we can tweak the workflow as needed to work better for our flow. This handbook doesn't describe every aspect of how a sprint system should work, but focuses on the specific choices our team made as we evolved our agile process.
As we evolve the system, it's helpful to know what our goals are. That can help illuminate whether a problem with the system is worth solving, and how to solve it without compromising on the essential things that make the team run smoothly.
Focus on the team's work
Our goal is for our team to deliver the most valuable work for the business and our users, every sprint.
This description from Scrum: A Breathtakingly Brief and Agile Introduction nails what that means in practice:
The role of each and every team member is to help the team deliver potentially shippable product in each sprint. Often, the best way to do this is by contributing work in their area of specialty. Other times, however, the team will need them to work outside of their area of specialty in order to best move backlog items from "in progress" to "done." What we are describing is a mindset change from "doing my job" to "doing the job."
We aim to complete 100% of our work every sprint. In practice this is rarely attainable: We know that dates will move, scopes will expand, or our estimates will be wrong. But we've found that this 100% benchmark ensures we prioritize our shared team goal (the sprint), rather than our individual deliverables.
Maximize swarming
We want writers to build expertise, but we don't want to isolate ourselves. An team at New Relic summed it up nicely:
Our philosophy is, "The team is the unit of work." This means that teams contribute to projects, teams solve problems, etc. We don't assign projects to individuals, and no one should ever be a single point of failure in the organization. If your team struggles to function effectively without you, your flexibility to take time off will be very limited. In such a case, we need to improve the skills and overall health of your team, ensure the team is setup for success, and ensure we have an appropriate team structure and charter in place.
And an ops team demonstrates the most important practical implication:
Our intention for tickets is that anyone should be able to select a task and have the information needed to understand and start on the work.
Sometimes, this means we work a little slower in order to learn or teach something---and that's okay! Ultimately, working this way makes our team more resilient and makes it easier for New Relic to get consistent, high-quality docs. The Ticket best practices doc describes in detail the rules and best practices we've discovered help us achieve this.
Enforce our points budgets
Our team votes on all stories brought into a sprint, and we cap the number of stories based on our points budget. We generally vote as though the least-experienced person on the team will take the ticket.
Having a strict points budget allows us to protect the team from overwork, predict our velocity over time, and ensure we actually have enough time to finish our work.
Work incrementally
Our goal is to deliver value as often as possible. Work that sits in a draft state for a long time can easily become wasted work: SMEs can become unavailable, priorities can change, and our knowledge can become stale. In practice, this means we work in short one-week sprints, publish early and often, and plan our projects so we can easily deliver 70% and then pivot to different priorities if something more important comes along.
Encourage self-service edits
Anyone can edit our open-sourced docs. With hundreds of Relics and users editing the docs each year, we can spend more of our writing time on high-impact work rather than simple maintenance edits.
In order to reward teams that help us work this way, we prioritize this work in our queue. For work the writers need to do themselves, we ask for at least one full sprint of lead time. If someone comes to us the Tuesday after a sprint starts, that means they could be waiting up to two weeks for us to kick off work! But if someone edits the docs themselves, we promise to get their edit live within a 1 to 3 business day SLA.
This lets us create win-wins: Rather than a simple "no," a requestor can decide whether they truly need that content out now (in which case they can create that first draft) or whether they're okay waiting a week or two.