Skip to content

Project Planning

This document explains how we use Trially documentation templates like the Project 1-Pager and Architecture Design Document to plan out existing work.

Most of the time, new projects due for a full planning process should have spawned in our Featurebase Roadmap, informed by user feedback and prioritized by our Product team.

Getting Started

  1. Determine if the new unit of work has an existing Project 1-Pager or Architecture Design Document
  2. If it does not, create a Project 1-Pager or Architecture Design Document as appropriate
  3. Products or significant new features should get a Project 1-Pager, and likely one or more Architecture Design Documents
  4. Technical improvements or other work that doesn’t directly roll up to a customer-facing experience can skip the Project 1-Pager
  5. Create Issues within Projects (which roll up to Initiatives)

Project Planning Flow

Concepts

Initiatives

Initiatives help maintain alignment and monitor progress. Projects roll up to Initiatives. It also makes work more transparent by giving context on why it matters.

Initiatives should be directly linked to company goals.

Projects

All projects should roll up to an Initiative. If it’s unclear what Initiative it should roll up to, let’s talk about it, maybe we need to expand our initiatives.

Issues

Issues should describe a task clearly and concisely. It needs to share enough so that the assignee can perform it and give enough context so that it’s easy to understand what work is being done. The user experience should be discussed at a product and feature level (roadmaps and projects), not at the issue level.

An issue description should define the task and its outcome. If it’s not a task then it doesn’t belong on the issue tracker.

Issue titles should be short, easy to scan, and descriptive.

Everyone on the team should write their own issues. This encourages the owner to think about the problem at a deeper level and increases the potential for the discovery of better solutions.

Sub-Issues

If you discover an Issue needs to be even further broken down, you can split an Issue into Sub-Issues within Linear.

Methodology

Using Initiatives

Define the Initiative

Initiatives are how we define strategic execution and have a monthly, quarterly, or yearly duration. Initiatives should link directly to company goals.

They are defined on a monthly/quarterly basis involving both technical and non-technical stakeholders.

Using Projects

Define the Projects

Projects should be defined with clear goals, expected outcomes, and timelines. Each project should have clear ownership. Usually a project will start by defining an Architecture Design Document.

Set Weekly Milestones

Projects should have weekly milestones to ensure progress is being made. Milestones are usually defined on a per engineer basis. Where an engineer is directly responisble to accomplish the work needed to complete that milestone.

Give Weekly Updates**

Projects should have weekly updates to ensure transparency and alignment. Project updates should be given on a per project basis and address the status of the milestones, any blockers, and any other relevant information.

Use the following format for project updates:

What did we accomplish last week?
What are we working on this week?
What are the blockers?

Weekly updates should be a function of milestone status. If the weekly milestones are being met then the project is on track, if the milestones aren't met but will be completed during the week and leave space for completing the current's week milestone then the project is at risk, if the milestones aren't being met then the project is off track.

Using Issues

Define the Issues

Issues should be defined with clear goals, expected outcomes, and timelines. Each issue should have clear ownership.

Estimate the Effort for each Issue

Here's a guide on how to estimate the effort for each issue.

Add relevant labels to each Issue

We have 2 types of labels:

  • Area of Work: This is a label that indicates the area of work that the issue is related to. e.g. data engineering, backend, frontend, etc.
  • Type of Work: This is a label that indicates the type of work that the issue is related to. e.g. feature, bug, improvement, etc.

Write documentation for each Issue

Each issue is considered as having two tasks. One is the implementation of the actual task and the other is the documentation of the changes.

Bugs and Improvments

Engineers are expected to spend most of their time spent on issues that are part of a project. However, they are also expected to allocate time for bugs and improvements. Here's documentation on how to allocate engineering time between projects, and Bugs and Improvements.