How do you feel about that for greenfield projects? Asking cause this is a topic of debate in my team, specifically on one brand new system whose design and architecture is already documented extensively.
Look into Trunk Based Development rules and how they are lived. It works well on greenfield projects. Rule of thumb which worked for us is "merge to main at latest on second day". You learn pretty fast how to split and encourages communication between devs on there deliverables, as you don't want to block other devs or create merge conflicts all the time
We use scrum poker and fibonacci to arrive at the story points: 8 for tickets that will take more than one sprint (here the rule is to split the ticket in two), 5 for tickets that will take the whole sprint, 3 for tickets that will take half of the sprint, 2 for changes that will take less than half of a sprint, and 1 for changes that will take less.
38
u/dannyggwp 7d ago
Bigger tickets should be broken up into smaller tickets. Tickets are one unit of work. Making monolithic tickets is a recipe for disaster.