Skip to content
This repository has been archived by the owner on Feb 8, 2023. It is now read-only.

Latest commit

 

History

History

OKR

Objectives & Key Results

The IPFS Working Groups use OKRs to communicate quarterly goals and measure progress in each objective. Most Working Groups do the planning of the OKRs in the open. In this folder, you can find the OKR docs which serve as anchors for the discussion every quarter.

OKRs by Quarter

If you want to see all working group OKRs at a glance by quarter, you can look at the quarterly OKRs sheets:

2020

2019

Notes on OKR Planning

We use OKRs to plan 60% of our time during a quarter. As creators and maintainers of a very live and large open source project, we made the decision to acknowledge that there are just way too many unknowns (bugs, regressions, infrastructure, events) that we can't possibly plan for and therefore, we are very generous to ourselves into locking 40% of our time to do just that. Of course, this doesn't translate to time wasted if there are actually no unknowns, what ends up happening is that IPFS contributors use the 40% to chase side-quests that can be valuable for the projects they are working on or for the ecosystem in general. We acknowledge and celebrate these side-quests in our end-of-quarter retrospectives.

To prepare the next quarter, we encourage Working Groups to adopt two outstanding healthy habits that have emerged from other IPFS Working Groups. These are: Running a Async Retrospective of the Quarter and Planning OKRs in the Open.

Async Retrospective of the Quarter

Running an async retrospective will give everyone in the team to clearly communicate what was achieved and not achieved in the quarter. It will also give the opportunity to signal things that can be improved and these can go from communication, structure, launch of features or anything that a team member finds important for the team to know.

These retrospectives enable us to check in with ourselves and prepare the following quarter better taking into consideration everything happened in the past. It also gives our future selves a way to check in with the past and see how far we have progressed.

You can see a great example of one of these with the JS Core Dev Q2 Retrospective. The whole team got to voice and learn from everyone else perspective.

We have reached a format for the retrospective that is quite simple and easy to complete. With the Template, all you need to do is to create a copy of this doc and share it with your Working Group members.

Planning OKRs in the Open

This is one of my favorite practices that has emerged in the IPFS Community by the IPFS Working Groups, planning OKRs in the Open.

The typical way to do this is simply by opening a PR on the entry point repo of the Working Group. In this PR, everyone gets to share their own view of the world and describe which Objectives and Key Results should be tackled for next quarter, community and users included!

Once everyone has shared theirs, the Captain takes the role of crafting a version of the final possible list of KRs based on everyone's proposal and needs of the project. Only then, people volunteer to take on certain Key Results and assign Priorities Collectively.

A suggestion is that each individual should not take anymore than two P0 items (unless they are quite small tasks). There are no recommended limits for P1, P2, P3 and P4s.

Also, if you know if you have holidays, conference attendance or some other event planned, do the timing exercise to make sure you are not trying to allocate too much work for the time you will have available. Another golden rule is to take the number of days in the Quarter (Q4 is 12 Weeks, that is 60 days) and take out the days you will be out and then plan for only 60% of that time. We propose to save 40% of time for putting out fires or surprise endeavors that always appear during the quarter.

Just for an example, given that the quarter is 60 days, imagine that I plan to take on 8 days of time off and spent 10 days attending/speaking at conferences, I realistically only have 42 days total. If we assume a work day of 8 hours a day, that is 336 hours. Cutting that to just 60% means that I have roughly only 201.6 hours of work I should plan for, otherwise I risk of not being able to achieve my KRs which might be dependencies of other projects.

Find great examples of this being done in the past at:

These PRs become records of the reasoning behind deciding on each KR.