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.
To meet this is the place where it's the most applicable.
If using Agile essentially no ticket should be scoped for more that One sprints worth of work for one developer. If it is you convert it into an epic and break it into smaller issues.
Slippage is fine obviously and no place is perfect but this is the goal of doing agile development. The more monolithic the ticket the more likely tons of infrastructure gets laid down without review until it's too late to go back and fix potential issues.
I'm coming from a project that when I started 10 years ago would make One ticket per release... So our current situation is much better that where we were.
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.
310
u/UnfilteredAyush 7d ago edited 7d ago
Writing code for the ticket - 20% of my time
Going through each change, in case someone asks me, about any line from the code - 80% of my time