# Notes for planning docs / workflows / OKRs Purpose of planning documents: 1. Firstly, creating the document acts as a brainstorm session for team members and helps to define the work that needs to be done for the coming Qs. Feature/Product direction should ideally come from executive management and product council (based on user research/interviews and requirements gathering/business development) 2. Alignment of goals across teams/orgs (sharing road maps) 3. Act as a north star during the Q. Semi regular check-ins enable the team to reflect on the work they are doing and to ensure that they are on track / focusing on the right things. 4. Provide visibily to executive managemnet on each teams progress and goals for a particular timeline. 5. Provide visiblity to external teams (in the open source community) Tendermint / Hub Approach (More focused on workflows than OKR style) Positives: - I like the way that the epics first acknowledge the user concern for each feature. - Each epic has a performer / champion which helps with accountability - I like the seperation of the (user) result and the expected (perfomer) activities. I think this helps to frame the conversation in the context of requirements gathering - I think having a longer timeline (not just one Q) helps to provide long term vision and direction. Not all projects can be completed within a single Q. - The template allows for a larger vision and I can see how using this model can help integrate several teams into the planning process (internal/external/open source community etc) Negatives: - I found some sections a bit wordy and overall the documents are a little bit tough to parse initially. You need to spend some time going through it as there is a lot there. - The activies/results are mostly binary in terms of measuring completion. Something is either done or not done. This makes it more difficult to do check-ins and does not provide much visibilty in terms of progress. IBC approach (OKRs) Positives: - Minimalist and easy to parse. The Objects are direct and the key results are concrete tasks achievable within a Q. - Because of the minimalst approach the OKRs can be written in a single day (1 or 2 sessions) - Key results are measureable with percentages. The OKR philosophy is 70% is considered a success. This makes it easy to track progress and do semi regular check-ins Negatives: - OKRs lose perspective on the bigger picture and longer term goals (6 months+) - Not much visibilty on the user problems being solved or the end result (the result for the user not the expected activities)