However, your example is unrealistic - you wouldn't split that task into two. If it won't fit comfortably in the sprint it waits for the next one.
It varies hugely by team and process, but where scrum/sprints are a good fit a reasonable first level of sprint loading seems to be a limit at about 70%. E.g. if an engineer has ten days available to work in a sprint, no more than 7 days of estimated work are pushed their way. The other 30% is assumed to be code reviews, meetings, pairing, bugfixing etc.
If that 70% is too high or low, it can be adjusted.
For everything else, there's Kanban.
That will never be how it's done. You work on it however long you can on this sprint and then finish it in the next one. So now you have two choices: either break it down in a completely arbitrary way into two stories, one for each sprint. Or just completely ignore the sprint boundary nonsense and just work on it.
Either way, it highlights how dumb it is to put silly boundaries on work delivery. Accomplishes nothing other than to waste people's time.
It works because your stakeholders see that you're actually delivering what you said you would _when_ you would, and that gets you the buy in and authority to run the team in a sane and sustainable manner.
For what it's worth, I prefer Kanban in most cases - but both are just different ways of managing WIP, utilisation and delivery time.
There is a clear rational purpose to breaking tasks up into parts. There are atomic units of work. Very few tasks can't be broken up into two-week segments.
This makes absolutely no sense to me and it is not how we do things at work. When the second task is estimated it will get a story point count of 1 because it's just copy pasting a button, not 5 which requires implementing a button from scratch.
you may not respect academic software engineering, but if this is true you have just created a perpetual motion machine.
changing / adding software to a system becomes more expensive (takes more time) as the size of the system increases. and it is not linear.
This makes no sense, nobody works like that. And to be fair, shouldn't.
The next button is a 1 point story because the component is there already. Or not even 1 point, may get buried in a 1 point story to add ten new buttons.
> Scrum does NOT work with deadlines.
No true Scotsman, we're all holding it wrong.
Deadlines will be imposed from afar, in just about every company ever, and then the points will be attempted to be retrofitted to the predetermined plan.
When approximately everyone, for a couple decades now, is always "doing it wrong", it's time to acknowledge that the problem is the idea not the people holding it wrong.
> The rational purpose to sprints is for project management to be able to look ahead and be able to say "we expect this feature to be done in X weeks time"
This is how that goes:
PM: It'd be great if we had all the stories and their points in the place for the next quarter so we can predict good dates, get on that will you?
Eng: Awesome! So I'll need to plan out the work for the quarter, write stories and estimate them. Nice, will do that.
PM: NO! This is agile, don't ever look beyond this sprint. We don't do planning in agile. Just work on your microtask of the sprint, we'll worry about next sprint later.
Eng: Um, wait, what?
You might again say they're doing it wrong. There's no true agile scotsman.
4 days is too long for them to wait, they get antsy and think nothing is happening if you can't actually show them something they can understand in a day or two.
I think it actually affects the code, everything has to be taped together tiny bits, because you can never do anything that doesn't show results fast, so you if you need a framework or an architecture or a plugin system, it's really hard.
But agile says that's fine because you're going to be doing first drafts and throwing away code anyway....
I don't think so. That's why sprints are so toxic. It's even right in the name. A 100m run is a "sprint", but nobody expects you to maintain that pace for a marathon. Much less for a multi-decade career. But in software you're expected to be in a sprinting pace all life long. And even increasing your "velocity" constantly. If that's not a death march, what is.
> Sprints are just a way of breaking up work into discrete periods of time.
There is not rational purpose to this. If the work takes 4 days, there's no reason to fabricate an artificial sprint boundary that forces you to break it down into two 2-day tasks just to fit into the confines of this imaginary sprint. It'll still be done four days from now.