🎟 Tech Delivery Blueprint (Agile)

Overview of how i've seen Tech delivery done well, for you to use as a blueprint when creating your squads

Transcript

1. ! TECH DELIVERY BLUEPRINT MODERN SOFTWARE DELIVERY FOR YOUR TEAMS CALLUM SILCOCK / CSI.LK
2. 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
3. │ ┌─────────────────────────┐ .─. .─. │ │ ( ) │ ( ) │ ┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─▼─ ─ ─ ─ ─ ─ ┌`─'┐ 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
4. ! REQUIREMENTS GATHERING - Design - Technology - COps - Users / Customers - You
5. ! 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)
6. ! 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)
7. ! 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
8. ! 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
9. ! STORY ESTIMATION - Dev / Lead (no need for product) - Go in with no context - Write down assumptions - Throw things back to product - COMPLEXITY NOT TIME
10. ! 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
11. ! 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
12. ! OTHER TICKET TYPES - Bugs - Spike - Task
13. ! WHAT HAPPENS WHEN THINGS GO WRONG? - dropping stories - re-estimating - canceling sprints half way and starting anew - P1s
14. ! 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
15. ! RETRO - Go over last retros actions - Went well / Didn't go well - Ideas - Cake (congrats, applause) - Create and assign actions
16. ♻ REPEAT!
17. ! 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
18. ☑ 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?)
19. !" THANKS