@[deleted]
It is challenging to have a one size fits all. I would lean towards options 2a or 3.
Opt 1. In my experience, separating UX from Dev creates more challenges with new/ changed requirements unless their communication is 100%. You lose transparency by creating, in effect, two teams for each product.
Opt. 2 using labels, components, custom fields to tag UX can work. The challenge is estimating story size and forecasting. The team needs to understand and agree on how long tasks take and definition of ready and done. If UX and Dev has not worked together, expect additional communication effort and adaptability. It requires a bit more planning up front so the team can understand what each is doing for a story.
Opt 2a. Use sub-tasks. Everyone gets a task and estimates their time. It can be as detailed as the team or org needs. The team can refer to specific work items and enhance inspection and transparency. The negative is it can slow things down, similar to option 2.
Opt 3. Using a new column(s) is usually less painful in the long run if the team uses status to move a story through development. If UX discovers new requirements with the customer, then a new story manifests to the backlog. the dev team can pull it into the current sprint if they have capacity, leave it into the backlog for future work, or negotiate with the product owner to bring prioritized new work and stop work on existing/ ongoing work.
Hope this helps
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.