I a big believer in the fact that splitting tasks into little micro bits that we work on in isolation is really holding teams back. Sizing work so that it's big enough to be of some value delivered to your users is a great way to actually getting your team thinking about the big picture and the impact they're having and to encourage your team members to work together on delivering that value.
You don't need to slice and dice stuff into tiny tasks. You don't need a manager handing these tasks out to team members. You can have teams that self organize and have a laser focus on the impact they deliver.
I'll admit I'm quite biased as I'm the founder of a startup [0] that builds a product management tool that encourages teams to have larger work items where they can capture a whole "unit" of value delivered to users. Teams use our work items to write a lot, attach designs, code snippets, etc. When they need to break down stuff, just add a todo list in the work item. We also don't have a notion of single assignees, but instead allow groups of users to be set as the team for a work item. My cofounder wrote a blog post on "right sizing" work items [1].
You don't need to slice and dice stuff into tiny tasks. You don't need a manager handing these tasks out to team members. You can have teams that self organize and have a laser focus on the impact they deliver.
I'll admit I'm quite biased as I'm the founder of a startup [0] that builds a product management tool that encourages teams to have larger work items where they can capture a whole "unit" of value delivered to users. Teams use our work items to write a lot, attach designs, code snippets, etc. When they need to break down stuff, just add a todo list in the work item. We also don't have a notion of single assignees, but instead allow groups of users to be set as the team for a work item. My cofounder wrote a blog post on "right sizing" work items [1].
0: https://kitemaker.co
1: https://medium.com/kitemaker-blog/right-sizing-elements-of-w...