meetings_how_to
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
| meetings_how_to [2020-06-01 15:10] – [Think Problems] tkerby | meetings_how_to [2020-06-08 01:05] – [Avoiding Bikeshedding] river | ||
|---|---|---|---|
| Line 24: | Line 24: | ||
| * Meetings should have a purpose. | * Meetings should have a purpose. | ||
| * Send out an agenda ahead of time, so that the purpose of the meeting is clear to all attendees and they can come prepared if necessary. Ideally this should include a quick background paragraph/ | * Send out an agenda ahead of time, so that the purpose of the meeting is clear to all attendees and they can come prepared if necessary. Ideally this should include a quick background paragraph/ | ||
| - | * After the meeting has finished, create | + | * Create |
| * Discuss this action list at the start of the next meeting if there is one. | * Discuss this action list at the start of the next meeting if there is one. | ||
| * Agree on a time limit in advance (eg an hour max) and try and stick to it: Better to have two shorter meetings with fresh people than one enormous mega-meeting that burns everyone out. | * Agree on a time limit in advance (eg an hour max) and try and stick to it: Better to have two shorter meetings with fresh people than one enormous mega-meeting that burns everyone out. | ||
| Line 38: | Line 38: | ||
| ===== Avoiding Bikeshedding ===== | ===== Avoiding Bikeshedding ===== | ||
| Some general points on how to collaboratively solve problems. Key thing is to consider the problem fully before we all jump in with possible solutions. | Some general points on how to collaboratively solve problems. Key thing is to consider the problem fully before we all jump in with possible solutions. | ||
| + | |||
| + | See also: [[bikeshed|]] | ||
| === Think Problems === | === Think Problems === | ||
| Line 44: | Line 46: | ||
| * Use techniques such as shadowing, brainstoming | * Use techniques such as shadowing, brainstoming | ||
| * Prioritise solving problems that are urgent, pervasive and valuable | * Prioritise solving problems that are urgent, pervasive and valuable | ||
| + | * Write don and communicate the problems - e.g. user stories, use cases, personas, problem statements | ||
| === Think Requirements === | === Think Requirements === | ||
| * Remember there are multiple stakeholders - anyone with an interest has a voice (e.g. suppliers, potential users, others with opportunity cost) | * Remember there are multiple stakeholders - anyone with an interest has a voice (e.g. suppliers, potential users, others with opportunity cost) | ||
| * Document the problems as requirements that can be validated against when considering solutions | * Document the problems as requirements that can be validated against when considering solutions | ||
| - | Consider implicit requirements that are not communicated – and check them with stakeholders (e.g. tea must be in a mug) | + | * Consider implicit requirements that are not communicated – and check them with stakeholders (e.g. tea must be in a mug) |
| * Remember specifications describe solutions and requirements describe problems | * Remember specifications describe solutions and requirements describe problems | ||
meetings_how_to.txt · Last modified: 2020-08-10 09:26 by river