Sprint and Project Management

Aptible is a remote organization and much of our work occurs asynchronously. Working remotely and asynchronously poses some challenges. We use our Sprint and Project Management processes to help counteract many of these challenges.

Why Aptible “does” Project Management

Aptible will never build onerous or rigid sprint and project processes–it’s just not in our DNA. But, we have designed our Aptible Sprint and Project Management (“ASPM”) processes to help us realize some key benefits:

Beyond this, it never feels good to be unclear what is expected of you, or what you can expect your teammates to deliver. Poor project management is stressful: it makes for a less pleasing and more difficult work environment, and makes it less likely that we will achieve our mission or strategic goals.

How the ASPM Works

Using project management effectively requires commitment, but it shouldn’t be difficult or time consuming. We should enjoy outsized returns for just a little bit of time invested in project management.

With this in mind, we are continuously iterating on how we ask teams to use project management based on feedback collected via bi-weekly retros, team surveys, all hands meetings, and ad hoc discussions.

Sprint Cadence

Aptible works on 2-3 week Sprints. Sprints generally start on Mondays and end on Fridays. Sprint dates are posted in the Iterations section of Shortcut.

We typically extend the length of Sprints around holidays to account for time when our “office” is closed. We do not run a Sprint around major holidays (e.g. between Christmas and New Years).

Project Management Rules

These rules are what Aptible has agreed to with respect to defining and tracking work.

• Stories vs. Epics vs. Milestones vs. Tasks
  • Stories are typically the smallest unit of work that we use at Aptible. What’s a Story?
    • Atlassian defines Stories as one simple narrative; Shortcut defines Stories as the basic unit of work.
    • A Story must be achievable within a Sprint; if it can’t be, it should be broken into smaller Stories associated with an Epic.
    • Examples of a Story might be:
      • Write the Q4 customer newsletter
      • Update IAM permissions so that the restart operation works
      • Research tradeoffs of EKS
    • A Story must be associated with a Sprint OR have a deadline or both
    • A Story must have an owner
    • A Story must have an Epic, unless purely operational/transitory and not clearly relevant to broader company goals
  • Epics are collections of Stories that make up a broader group of work. Epics can be thought of as Projects.
    • Examples of Epics might be:
      • Year-end customer comms
      • 20.04 rollout
      • Any Cloud prototyping
    • An Epic has a status
    • An Epic has start/end dates
    • An Epic has an assigned owner(s) and team
    • An Epic is usually associated with a Milestone
    • An Epic spans multiple sprints
  • Milestones are bigger strategic goals.
    • Milestones cover a specific time period (have a start and end date)
    • Today, Milestones are tied to Company-level goals, but in the future we can use Milestones for more granular goal setting (e.g. team goals)
  • Tasks are generally frowned upon but can be used for quick to do lists
    • If you start collecting Tasks that require different ownership or due dates, it’s time to split each into a Story (which fortunately Shortcut has a specific button for)
    • If you associate all these Stories that were converted from Tasks to a specific Epic you will be able to track progress collectively across the Epic, using the Epic view
• Process
  • Teams should work together to define Stories and Epics
  • Daily Updates: Individual Story and Epic owners are responsible for keeping status, start/end dates, comments, etc. updated. ** We ask for updates on In Progress work at least 1x per day ** It’s also a good idea to at least 1x per day consider whether your work is appropriately represented in Shortcut. If it isn’t, you should create additional Stories and Epics. If you are unsure, talk with your manager.
  • End of Sprint / Sprint Forecast
    • If a Story is likely to remain unfinished at the end of the Sprint, and no later than 2 days before Sprint close, functional leads (or individual team members) should:
      • Add the label Likely Unfinished During Sprint.
      • Comment re: Estimated time remaining
      • Comment re: Perceived blockers
      • Comment re: When we should return to them (next sprint or some other time)
    • During Sprint planning, we will move Stories with the label ‘Likely Unfinished During Sprint’ (and remove the label) as needed

Project Management Guidelines

These guidelines are just recommendations, not hard-and-fast rules. However, we believe that the closer we can align around these guidelines, the easier and more beneficial project management will be for Aptible and for each individual team member. Have a suggestion for how we can improve? Don’t be shy: open a PR or raise for discussion during our next Retro (or async via Slack).

• Five minute rule. If something takes you more than 5 minutes, and it isn’t logged in Zendesk (e.g. a Zendesk ticket) or tracked in our CRM, there should be an associated Story or Stories in our Project Management tool.
  • Obviously not every 5 minute task deserves a Story, but this is a heuristic to evaluate when to create a Story vs. just to complete the work: ideally, any significant work would be documented and prioritized for future reflection/evaluation.
  • For a specific controversial example: writing an email response that takes more than 5 minutes doesn’t feel especially relevant to track in a project management tool. But, if that email response is in a running thread with a customer where we are working through a topic that will require multiple rounds of followup to get to resolution, that should likely be managed through Zendesk or, if not, logged as a Story in Shortcut so we don’t lose track of the work.
• Daily Status Updates and Comments. At least 1x per business day, you should create any new and update active existing Stories and Epics: ensure that the State for each Story and Epic is current, and leave comments addressing your progress so anyone can see and follow along.
• Limit the use of Subtasks. Use Subtasks sparingly - default to creating separate Stories under an Epic, so each Story can have a discrete deadline. Subtasks are fine for simple items, but often it is better to create separate Stories for discoverability and flexibility to set specific deadlines, owners, etc.

Additional resources

• Using Shortcut