Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,639,445
Community Members
 
Community Events
196
Community Groups

How can I have story points count as complete in a sprint without the task being completed?

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?

1 answer

0 votes
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
Sep 17, 2021

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.

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events