I don't know how it is where you work (I guess working as a contractor skews things) but where I work this is how things go:
- some tasks are estimated
- a resource bound is set per sprint/per person
- tasks are picked for a sprint such that the resource bounds aren't exceeded.
- people work on those tasks until the next sprint.
Now, software engineering is notoriously hard to estimate. Hard to predict you can't work for 2 days because someone updated a package that totally follows semver except not really and it takes 3 days of debugging.
So tasks get estimated with a lot of slack because hitting the sprint targets is more important than doing more work. That's a process problem.
Even then what mostly happens is that some tasks end up wildly overestimated while others wildly underestimated, to the point they end up shifted to the next sprint (at which point one must question the whole exercise).
This all assumes the requirements for the tasks were in any way clear, often they aren't.
Either way, the outcome is that some weeks there simply isn't enough work assigned, while others there's too much. Sometimes there's an issue that's on someone to fix and everyone else is waiting for that before they can do their work.
What should they be doing with their time? Improve the tests? The docs? I guess, but unmotivated people doing boring work always ends up with a shitty output regardless of how many hours they dedicate to it.
Much better to trust people to get the job done, given them a reason why they do what they do, and set processes that let them work at a consistent pace. That's what Agile was originally all about.
(I know you’re a contractor so you don’t get to choose but:) stop working in artificial sprints. In some cases they’re useful(external client stuff) but mostly they can be replaced with just working down a continuous backlog. Then you don’t have this weird artificial feast and famine game.
I think from your last sentence you agree.
- some tasks are estimated - a resource bound is set per sprint/per person - tasks are picked for a sprint such that the resource bounds aren't exceeded. - people work on those tasks until the next sprint.
Now, software engineering is notoriously hard to estimate. Hard to predict you can't work for 2 days because someone updated a package that totally follows semver except not really and it takes 3 days of debugging.
So tasks get estimated with a lot of slack because hitting the sprint targets is more important than doing more work. That's a process problem.
Even then what mostly happens is that some tasks end up wildly overestimated while others wildly underestimated, to the point they end up shifted to the next sprint (at which point one must question the whole exercise).
This all assumes the requirements for the tasks were in any way clear, often they aren't.
Either way, the outcome is that some weeks there simply isn't enough work assigned, while others there's too much. Sometimes there's an issue that's on someone to fix and everyone else is waiting for that before they can do their work.
What should they be doing with their time? Improve the tests? The docs? I guess, but unmotivated people doing boring work always ends up with a shitty output regardless of how many hours they dedicate to it.
Much better to trust people to get the job done, given them a reason why they do what they do, and set processes that let them work at a consistent pace. That's what Agile was originally all about.