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:
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).
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.
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.
Hi Atlassian community, My name is Max and I work on the product integration team at Atlassian. I am pleased to announce the early access program for the Jira Cloud add-in for Outlook. This add-in...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events