# Day 1 - Friday # Migrations - Rather than split by component, split by functionality/customer cohort - That way you can target cohort with minimal features, and move customer by customer for the migration rather than component. https://app.mural.co/t/industriallogic9109/m/industriallogic9109/1685722000528/f6a121a1f035243e50559f0c544ebe1a41c7a91f?sender=61d3a46d-a8ca-43b6-8639-7ac1a22ab181 ![[Screenshot 2023-06-02 at 17.58.07.png]] # Day 2 - Saturday ## What the hell is BDD? Handled sequentially: - Discovery - Example mapping is one good way of doing this - Concrete examples help our understanding - Rules can be misinterpreted, but concrete examples are much harder to be misinterpreted - It can be helpful to focus on one story in a day when doing - 30m after standup - Should be having a conversation with notes - If there is not enough expertise in the group, don't speculate between yourselves, mark as an unknown and assign an owner to get an answer. - 3 Amigos is one form of discovery - Too many is not good, but 5-6 is actual ideal - Formulation - Cucumber uses gherkin, given when then - Once we have example mapping, a pair can write them up together - Encourage not to include PM - It is essential that the PM review the result - Should be committed to code base - Automation - cucumber, specflow, behat, go dog A common misunderstanding is you MUST follow all 3. A large proportion of value actually comes in Discovery phase, so would be better to do only this, than say just write automated tests using cucumber. Strongly advise not to write into Stories/tickets. If you need to, link to Miro etc. of example mapping. Stories are not specifications, they are a way of breaking down value "A story is a reminder to have a conversation" g-w-t should be 5 lines or fewer wrt example mapping BRIEF: Business readable Real data Intention revealing Essential (for which rule this written) Focus You could add incorrect stories as a test that they have been reviewed