You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
Our workflow uses a Ready for QA status, but we usually don't QA until after the sprint is complete. But since it's not considered a "done" task, the tasks are considered incomplete when we close the sprint. We consider that done and would like to have the story points be considered complete so we can use our sprint reports and burn down charts. We don't want Ready for QA to be a done status because we worry that they will get lost/missed, since they will no longer show on the board or backlog once the sprint is complete.
What's the best way to use Ready for QA in our Scrum process in jira? How are other teams using it?
There's no way to do this. One of the important parts of Scrum is the definition of done, and measuring your delivery against commitment is done on, well, what you've delivered. You don't count things as done until they really are.
In a Scrum team, QA is supposed to be part of it. The whole point is that the team, whatever its composition, delivers something for the product owner when the story is complete. Not "something that we built but haven't tested", but something that could be given to a customer.
But. If you're not going to do that, and you consider "ready to be tested" to be the deliverable, you can work with it. The trick is to stop thinking that QA is part of your development team's process. You shift the deliverable from "an item to be considered to go to the customer" to "something ready to throw over to the test team". You excise the testers from the team and treat them as external and absolutely not part of your Agile teams or process.
Then you change the board. A board generally represents a team's work, and your testing is nothing to do with your team, so you get rid of it.
Imagine a simple workflow of: open -> in dev -> ready-to-test -> in-test -> done
Your development board should have columns mapped with the status open, in-dev and ready-to-test - ready-to-test being the last column on the developers board, and hence "done", so the estimates now burn down as the development team deliver.