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.
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:
Challenge | ASPM Benefit |
---|---|
Hard to see how my work fits in with broader company goals | Create alignment by clearly connecting individual units of work (Stories) with company strategic goals (Milestones) through Epics |
Hard to know what everyone else is working on | Drive clarity by enforcing a Sprint structure and Sprint-planning process where we clearly lay out the Stories that will be completed within a Sprint, and keep those Stories up to date |
Easy to get distracted by new ideas or initiatives | Enforce focus by ensuring all work is clearly documented in our project management system rather than via Slack conversations/threads |
Hard to know who is doing what or if we are succeeding or failing | Promote accountability by assigning Epics and Stories to teams and individuals, and setting reasonable deadlines |
Wasting time by forgetting or re-litigating already-made decisions | Documentation in the form of clear descriptions on Milestones, Epics, and Stories that is referenceable by all team members–nothing of consequence should be only findable by searching Slack |
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.
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.
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).
Day relative to Sprint Start | Item |
---|---|
Sprint Kickoff Day -1 |
* During all hands or async, leadership team provides any feedback/guidance on subsequent Sprint to “kick off” Sprint planning |
Sprint Planning Day 1 |
* Functional teams create and assign Epics and Stories for the Sprint, tying all Stories to an Epic and all Epics to Milestones * Functional teams should move all previous Sprint stories that are incomplete to the subsequent Sprint * Functional teams can also move Stories that are not ready for immediate prioritization to future Sprints |
Sprint Feedback Day 2 |
* CEO and COO provide feedback (async or sync as needed) on Epics/Stories created on Day 1 |
Sprint! Day 1-10/15 |
* Once Stories are set, team members should begin progressing on Sprint, keeping Story and Epic states and comments up to date |
Sprint Forecast Day 8/13 |
* 2 days before the Sprint is to end, functional leads should create a list of Stories that will likely not be finished during the Sprint * These Stories should likely have been broken into smaller Stories -or- were incorrectly prioritized / or we misunderstood something about them * Unfinished Stories should be tagged with the label Likely Unfinished During Sprint documenting with a comment explaining: ** Estimated time remaining ** Perceived blockers ** When we should return to them (next sprint or some other time)? * At the Conclusion of the Sprint, we’ll move any unfinished Stories with this label to subsequent Sprint(s), discuss them if needed during the Retro, and subsequently remove the label |
Sprint Close Day 10/15 |
* On the last day of Sprint, each team shows the progress, learnings, and outcomes from the Sprint |
Sprint Retro Day +2 |
* A few days after the Sprint Close, Retro the previous Sprint live to collect feedback and discuss how we can improve |
These rules are what Aptible has agreed to with respect to defining and tracking work.
Write the Q4 customer newsletter
Update IAM permissions so that the restart operation works
Research tradeoffs of EKS
Year-end customer comms
20.04 rollout
Any Cloud prototyping
Likely Unfinished During Sprint
.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).