4 ms·
The rational purpose is this: sprints should be a way of trading off lower utilisation for more predictable delivery. However, your example is unrealistic - yo
by mjfisher 3y ago
The rational purpose is this: sprints should be a way of trading off lower utilisation for more predictable delivery.
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.
- jjav 3y ago> If it won't fit comfortably in the sprint it waits for the next one. 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.
- mjfisher 3y agoSorry, but that blanket statement is just wrong. That is _exactly_ how it's done when I run a scrum team. If it stops being a good fit or working well for any number of reasons, we stop and look at the process. 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.