Skip to content

Standups

We do standups three times a week on Monday, Wednesday, and Friday mornings to break articles into smaller tasks and set short-term goals.

While our main project management is done on our ritza-articles board at an article level, standups are intended to help writers avoid getting blocked and stay motivated by achieving smaller goals. Breaking a project into smaller tasks also allows for more collaboration as others can help or take over a smaller piece if necessary.

Goals of standups

The goal of standups is to:

  • Allow writers to interact more with a team, as some people find it isolating to work alone remotely all day.
  • Divide stuff into manageable pieces and avoid writer's block or being overwhelmed by having a 2-3 week task at "blank page" stage.
  • Increase collaboration and have writers help each other out with writing or technical problems.
  • Provide an up-to-date source of information to inform delivery estimates of larger projects.
  • Help writers get better at estimating the time needed for tasks.

The goal of standups is not to push writers to work faster, produce more, or be in "constant sprint" mode. We hope that standups will contribute to an environment that's conducive to more productivity and output, but this should never be the goal. If standups result in improved productivity from burnt-out writers, they have failed.

Format of standups

Writers take turns in a synchronous call, spending 5-10 minutes each explaining what projects they are working on and breaking off tasks from these projects. They could also spend 1-2 minutes discussing previous tasks, and highlighting any learnings like incorrect time estimations.

The team lead actively interrogates each task, discussing it with the writer to help the writer break it down into pieces that make sense. The team lead discusses with the writer how they came to the estimated time and whether the definition of the task makes sense, and may provide advice or input if required. If a discussion looks like it will take longer than a few minutes, it should be noted and taken offline, for example, the team lead and writer can discuss it 1:1 after the meeting or on Slack later in the day.

Tasks

A task is a chunk of a project that:

  • May be done in more than three hours of work, but is often done in fewer.
  • Is a self-standing deliverable that can be shared with the rest of the team for feedback and review.
  • Is only a single kind of work, for example, coding, writing, or research.
  • Has a well-defined "done" state.

Writers working an eight-hour day should schedule no more than six hours worth of tasks for a given day, for example, a three-hour task for the morning and a three-hour task for the afternoon.

Good examples of tasks

  • Coding: POC code pushed to GitHub that demonstrates CRUD operations against the FooBar system.
  • Writing: The CRUD part of the FooBar article, showing users how to create, read, update, and delete data from a system, about 1000 words.
  • A half-page document summarizing learnings from some research about a new platform, for example, how to onboard to it, whether a free trial or sandbox exists, the state of the documentation, and an estimate on how difficult it would be to integrate with some other platform.
  • Fixing the infinite loop bug.

Bad examples of tasks

  • Working on foobar article.
  • Reading about the fizz platform.
  • Investigating the infinite loop bug.

Weekly cadence

Because we meet three times a week, each session is only concerned with at most two days, or a max of four three-hour slots for a full-time writer. So,

  • Monday morning, we estimate what we can do on Monday and Tuesday.
  • Wednesday morning, we estimate what we can do on Wednesday and Thursday.
  • Friday morning, we estimate what we can do for the rest of Friday.

The weekly tracking is not meant to be long-term, so it's not important that everything is perfect and cleanly recorded. Old tasks can simply be deleted rather than sorted into the correct place. The outcome of a standup should be that everyone has a clear idea of their goals for that day and the next day.

Sharing work in small pieces

Writers should post to #ritza-team, #ritza-<customer>, or #ritza-<writer> when they complete tasks, depending on who they would like to see the post. For example, if the task is something that is ready for editing or quality assurance, then it should be posted to #ritza-<customer>. If the task is only partial progress towards an article that doesn't need input from anyone else yet, then #ritza-<writer>.

When sharing work, writers should share a short (often one sentence) summary of what they did, anything unexpected that changed the original estimate of time for that task, and a link to where the work exists, like a GitHub link to code or Markdown, a Google Doc link to a research summary.

Getting help

If a writer is stuck on something, they should ask in #ritza-team, #ritza-<customer>, or #ritza-<writer> for help as soon as possible, either posting a detailed description of what they are stuck on so someone else can try to replicate the project to the point they are at, or ask for a call with someone to walk through it together and try to figure out the issue.