! TECH DELIVERY BLUEPRINT MODERN SOFTWARE DELIVERY FOR YOUR TEAMS CALLUM SILCOCK / CSI.LK 

There are many methods of how to do tech delivery, this is what I've seen work well, the idea is for you to use it as a blueprint not a ruleb k 

│ ┌─────────────────────────┐ .─. .─. │ │ ( ) │ ( ) │ ┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─▼─ ─ ─ ─ ─ ─ ┌`─'┐ Requirements ┌`─'┐ │ Todo │ Doing │ Review │ Done │ │ │──────│──────>│PO │────────┘ │┌───┬─┐│┌───┬─┐│ │┌───┬─┐ └───┘ └───┘ │ └─│││ └─││ ││ └─││ Design │ │ Create ││Story│││Story││ ││-----│ Tech ▼ └─────┘│└─────┘│ │└─────┘│ COps │ ┌───┬─┐ └ ─ ▲ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─│─ ─ etc. │ └─│ │ Kanban Board │ │ │Epic │ │ │ ─ ─ ─ ─ ─ ─ ─ ─ └─────┘ Create Sprint │ ▲ │ Breakdown │ ▼ │ ┌───────┼───────┐ │ .─. │ ▼ ▼ ▼ .─. ( ) │ ┌───┬─┐ ┌───┬─┐ ┌───┬─┐ ( ) ┌`─'─┐ │ │ └─│ │ └─│ │ └─│ Point┌`─'┐ │User│ │ │Story│ │Story│ │Story│─────▶│Dev│ └────┘ │ └─────┘ └─────┘ └─────┘ └───┘ │ │ │ └─────────────────────────────────────────────────────────────────┘ Analysis 

! REQUIREMENTS GATHERING - Design - Technology - COps - Users / Customers - You 

! CREATING EPICS - Product will generate these with help of the business owner - What are the must haves vs nice to haves - Start thinking about these from a user perspective - Validating the ideas are worth building for - What is the success criteria - Design / Tech input (eg. whether achievable) 

! EPIC ESTIMATION - Usually per quarter before defining your OKRs - T-shirt size - XS S M L XL - Can be tacked on to other meetings (eg. backlog grooming or sprint planning) 

! WHAT DO YOUR STORIES LOOK LIKE? - Given when then syntax (as a user) - Requirements based - Light vs Heavy - Whatever the format, your team needs to decide on it 

! STORY CREATION SESSION - Product / Rotating Devs ! / UXD - Take those epics and break them down - Write down what you think will help - Split between function or together 

! STORY ESTIMATION - Dev / Lead (no need for product) - Go in with no context - Write down assumptions - Throw things back to product - COMPLEXITY NOT TIME 

! SPRINT PLANNING - Product / All Devs - You need to know who is working - Figure out your velocity - eg. point per dev day / median points per sprint - Commitment 

! RUNNING A SPRINT - Goal - Stand-ups (they can be remote) - Blockers - Async and open communication is better - Write down things in the tickets you're working on - Don't bring things in, support others to finish tasks first 

! OTHER TICKET TYPES - Bugs - Spike - Task 

! WHAT HAPPENS WHEN THINGS GO WRONG? - dropping stories - re-estimating - canceling sprints half way and starting anew - P1s 

! SHOWCASE (DEPO DEMO) - be proud of what you've achieved - work does not need to be client facing to be demo-able - rotate who's demo-ing 

! RETRO - Go over last retros actions - Went well / Didn't go well - Ideas - Cake (congrats, applause) - Create and assign actions 

♻ REPEAT! 

! ROLLING THIS UP - Points > Velocity > Projected throughput in a (sprint length) period - Epic estimation (t-shirt) vs Epic actual points > Projected epic length - epic x was medium and when delivered was y points 

☑ THINGS YOU NEED TO DO - Sprint length - Story point scale / context (what's 0 / too complicated to point look like?) - How are you going to write your stories - How will you measure velocity? - Definition of done (merged? in production? passed experiment?) 

!" THANKS