Let's suppose, there is a task to add a new search function to a website. Let's also suppose this is a large task.
Do we use sub-task (e.g. Jira sub-tasks) for decomposition of a large task?
It is easier to track progress of small work items than big ones.
Personally, I think you do need to spend time and decompose your tasks. Looking at your examples, if you don't decompose, you'll end up with tickets that remain in progress for much longer than you prefer.
As a good example, let's look at Subtask 2
Implement the search function
You have presented this as if it has already been decomposed from the parent task of
Add a new search function to a website
But speaking from experience working for years with software teams, "Implement the search function" is itself far too broad, and it will remain as WIP indefinitely.
Appropriate (fictional) "sub-sub-tasks" for #2 could be:
Also sometimes in Kanban we don't estimate tasks, but if you do, you will absolutely need to decompose down to tasks that are capable of being estimated. "Implement the search function" is too broad and will never be properly estimated.
I would advise against a sub-task approach as it is often painful for Devs to have to update each sub-task with their progress.
A driving principle behind Kanban is to limit WIP (work-in-progress) and I think the way you approach your story writing should mirror this. In other words, consolidate the stories where it makes the most logical sense. My question for you is who is most interested in tracking each of these subtasks in this way? Remember, you want your board and the cards to facilitate conversation between the PO and the developers and not create unnecessary tedium for those actually doing the work. I hope this helps!
