If you have a software development project that includes multiple steps per story (UX, UI, Dev, Test, Documentation...) is it best to create a workflow or sub-tasks?

Bahareh Lameija

If I have my Epics and Stories defined and prioritized in my backlog, what is the best practice around managing the design, definition, development, and testing in terms of using a Workflow and changing the Assignee, vs. creating Sub-Tasks for each step? What are the benefits and drawbacks of using a Workflow to drive a Story's progress, vs. using Sub-Tasks? 

Nic Brough -Adaptavist-

Although workflows are not a series of linear steps, it's quite likely that your processes are.  Most people who define a workflow will give you something like "New, authorised, in progress, in test, done".  It's the route an issue should take if it all goes well.  In real life, that covers some of them, but a lot of issues will fail tests, not get done, not get authorised, get deprecated, duplicated or passed over,  and so-on, so a workflow should reflect this.

The question you need to think about is how your process should match.

If you have a story process that is ideally linear, so that a Story will go New, UX, UI, Dev, Test, Docs, Released, Done, then yes, do it in the workflow (even if it skips steps or you allow it to go backwards, it's fine).   Equally important is that it is being worked on by one person at a time.  So when it's in Dev, the assignee is the developer, when in Test, it's a Tester, when it's in Docs, it's the most appropriate person (maybe a tech author, or the developer again, or the BA, etc)

But, if your story process could run in parallel and/or have different assignees, then you want to sub-task it.  There's a lot of options, but here's a common pattern:

• Story has a workflow of New -> Approved -> Design -> Dev -> Testing -> Ready to release -> Done
• We create subtasks for:
  • UX and UI and don't move out of Design until they're done
  • All the dev items the developers want to break out for different developers to deal with
  • Any defects found in testing
  • Documentation tasks, often one, sometimes many (when docs would benefit from being written by several people - a dev, BA, user etc)
  • A task to represent implementation

There's lots of ways to approach this, but I think getting the linear/parallel model defined is a very early step.