Introduction:

The work of the Integrations Guild is mostly project based, meaning tasks are often unique, or limited to a specific period of time. The Guilds Objective and Key Results (OKRs) are determined for a period of 6 months, with a review and update moment after 3 months.

OKRs are often large, longer term goals. Some consequences of this

1. Hard to quantify status in between Start and Completed —> hard to track progress, take action when behind Example: Complete a tBTC integration. Without breaking these down in sub-steps it’s hard to determine being on track of not
2. Don’t necessarily have the same priority, or don’t necessarily need to be worked on a the same time. Example: Until the tBTC bridge is live, it doesn’t make sense to approach protocols. However, it does make sense to work on the pre-requisite for integrations
3. There’s potential contributors that look up to a large OKR, and feel this is not something they could own, or it’s unclear where they could support. Example: Secure 200 tBTC v2 nodes at the start of the tBTC V2 launch
4. Not full ownership / transparency. Being ‘on-track’ for an OKR can often be vague. Example: We’re in talks with 3 protocols, and things are looking good.

With sprint based working, these OKRs are broken down into smaller subtasks.

1. Subtasks are tasks that can be completed within a sprint, so at the end of a sprint it’s clear which tasks are and which are not completd
2. OKRs are translated into tasks in a timeline. This can also mean that some OKRs are not worked on at a specific time, which is ok because it was planned / prioritized this way. It allows the TIG to focus.
3. With smaller tasks, a contributor could grow into a role by completing sub-tasks, and gradually start to pick up more and larger tasks. Completing a task is also an achievement, which motivates, and can be compensated for. A faster, smaller task based compensation could be positive for retention of contributors.
4. Having a clear owner and due date for a task drives ownership. Even more so if this due date was proposed by the owner itself.
5. Smaller tasks make it easier to work async, which is important for our DAO
6. A sprint retro at the end of each sprint, reflects on the previous sprint.
   1. What went well
   2. What didn’t go so well
   3. What do we do different the next sprint

Having these short term reviews (simple! no detailed reports) allows us to improve our processes and also share successes and or frustrations early on.

How could this work for the TIG

Sprint duration: 2 weeks