- A technical planning meeting is an informal discussion aimed at streamlining our development processes
- They can be as short or as long as necessary
- They should be requested by developers
- When starting a new project
- When adding new features or functionality
- When undertaking anything that is likely to be more than 5 days work
- High level documentation of the business problem and technical solution
- Developers should have a clear understanding of what is expected
- A set of Sprintly tickets for product owners to prioritise
- A definition of done
- 1 or more developers with a technical challenge
- 1 or more software architects
- 0 or more database engineers (if database work will be required)
- 0 or more UXUI engineers (if frontend work will be required)
- 0 or more business owners (if the business requirements are sufficiently complex)
- 0 or more testers (if there is a large testing requirement)
- 0 or more project leads (if developers might require additional technical assistance)
- The developers explain the business problem they're trying to solve and open it up for discussion
- The developers explain their technical solution and open it up for discussion
- We exchange thoughts and ideas, fill in any blanks and compromise where necessary to reach a good solution
- We break the work down into small chunks
- If the chunks of work are small enough to begin work, raise some Sprintly tickets. Otherwise, arrange for future technical planning meetings to dig deeper into the problem
- The developers should leave the meeting and produce a markdown document covering everything discussed in parts #1 to #4
- Product owners prioritise the work as appropriate