Breaking down stories.

Question

Hi all,

I'd like to understand the best way to break down a user story into tasks so that a piece of work gets delivered.

For example, we require the features developed in User Story A, to be deployed to a testing environment (requires deployment by Employee A), so then the features can be tested by the testing team, and so on, until we go live.

My understanding would be that I would write out a story, and then break down the tasks necessary to deliver story. Which would look something like:

Story A:

Dev task

Testing task

Deployment task

The workflow for both stories and the tasks is set out as a simple: to do -> in progress <-> on hold -> done

Is this a correct understanding of how to break down and use stories? Once all of the tasks have progressed to a done state, as long as this has all been estimated correctly, the story can be closed.

We are discussing this internally and users are confused as to how they will know when they can start their piece of work. Some are asking how come they cannot "deploy" the story itself and I am left struggling to explain that they need to make a task for the deployment, and stories cannot be deployed (specifically I am getting requests for workflow steps called "ready to test", "testing", "deployment" etc. to the story issue type workflow).

Help?

Marianne Miller · Accepted Answer

Teodor,

I'm not sure what role you are currently serving, but your question makes sense from a developer's perspective.  We use a custom workflow and we do not use usually use tasks, as they can't be tracked in the Backlog/Sprint.

https://community.atlassian.com/t5/Jira-questions/showing-tasks-in-the-active-sprint-board/qaq-p/637822

https://community.atlassian.com/t5/Jira-Software-questions/Tasks-do-not-appear-in-the-Backlog-view/qaq-p/41997

We struggled with the exact scenario you are describing.  After a lot of research, and trial & error, we found a solution that works well for our Scrum team.

We ensure that the story has all the requirements and acceptance criteria needed for approval prior to Sprint Planning, and as a rule, we do not use tasks.  If these requirements need a breakdown, the developer themselves create tasks for their own work or others, but we manage this at the DSU.

We actually built a custom  workflow to track (most of) the states you referenced, as most users do want to know these statuses. This way, the developers mark something "ready for QA", and QA marks it "ready for demo", etc and set the board to "complete" when it meets our definition of Done, so our burndown is accurate.

There is a fine line to walk to work in the Scrum framework and within Jira's process flows.  They are compatible, but I've found a little Jira TLC goes a long way.

Good luck!