There are some things that we do as Developers because we are pragmatic. Take our shared libraries. They get worked on and reviewed/merged then they have to build for a few minutes and become nuget packages. We then have to update them into our web apps and this seems longer than necessary.

Imagine that we have a sprint with a load of separate tasks that all relate to the shared libraries, maybe even methods in the same class. Surely, it would make much more sense to bundle all of these into a larger task and do them all in one go. One change, one review, one build etc.

This seems to conflict with how most agile development processes work but it seems like a good idea right?

Well, no. You should NOT bundle work from several tasks into one task. Why not?

The essence of most agile methodologies is to add value quickly: ship a feature in the shortest time, ideally into production, so that customers are happy, business managers are happy etc. So why does bundling work not make sense in agile?

  1. You will take much longer to complete the task and would be blocking several stories until you are finished.
  2. If you have something picked up in a review, the entire task is blocked until you resolve it. If this is something messy, there might be pressure on the reviewer to let it through rather than delay it or you might fall down the slippery slope and end up with a large code change that is more brittle and less reviewable.
  3. Fast is good. Writing one method with a couple of tests should be very quick and easy. easy to review and low risk. Every additional piece of work you add increases risk.
  4. The code is actually harder to make reliable as you do more and more. e.g. 1 big fix takes longer than 4 smaller changes.
  5. You might miss details that are in individual tasks concerning each of the methods you are adding. Easier to concentrate on detail for one change at a time than try and get all of them correct in one go.
  6. The later stories might not get worked on and end up back in the backlog, you have therefore created functionality that was not needed and doesn't add a product increment. In fact, the story might be cancelled so you have now created an unused method, which is technical debt - it might get used incorrectly by someone else.
  7. A story that doesn't look worked on might be refined by the PO who wants the code to be implemented in a specific way, if you already did it, you lose this chance to make a change.
  8. Multiple people might change the same code because you took work from another task.
  9. The whole thing might be scrapped - better to scrap less code than more!