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

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


1 badge earned


Participate in fun challenges

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


Gift kudos to your peers

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


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!


in review stories moving to next sprint

My dev teams move stories to "In Review" once the development is completed and assign it to the PO for review. The issue is most of the time the PO does not complete the review before the end of the sprint .

This causes 2 issues

1) Work done by the dev team has no credit as the task is not "Done" . So when we review the velocity, there is always a wrong data


2) These tickets which are" In Review" by the PO move to the next sprint and give an impression that the next Sprint is loaded.


How do you manage such cases?

2 answers

Suggest an answer

Log in or Sign up to answer
0 votes
Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Jul 21, 2021

Hi @Agile Curve  -- Welcome to the Atlassian Community!

How about "take it to the team", and sit down with the product owner (PO) together to understand what you observe, why you hypothesize that is happening, and deciding how to experiment to improve the situation? 

There could be lots of reasons for this symptom, and without more information it may be challenging for others not present with your team to help.  For example:

  • How often does this happen?  If not often, why work on this?  What other issues could the team improve upon instead?
  • Is the PO spread too thin on capacity?  If so, why?
  • Is the team producing more than is sustainable for the team capacity?  If so, why?
  • Is the PO filling a QA role for the team?  If so, why are they doing that, and are there quality issues that, once resolved, eliminate the need for "PO review"?
  • etc.

Best regards,

Hi Bill, Thank you for the prompt response. The team wants me to look into this issue as a Scrum master. There is management pressure (which is not good) on why the velocity is low. The PO spread is thin which is one of the reasons for stories being in review. The PO says till I sign off the acceptance criteria and move it to done, your task is not done.

Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Jul 21, 2021 • edited

It appears you and the team have enough info to sit down with your product owner to discuss the problem and any experiment...

  • what is the problem we are trying to solve
  • what would better look like
  • how will we know it is getting better
  • how would we measure that
  • what are some planned steps toward better
  • take the first step
  • observe the results
  • repeat... (or PDCA to summarize)

If the PO isn't part of the solution-ing, what you describe seems to indicate the scrum team ("developers", PO, SM) will not get to your goal of fully delivering the valuable items at the end of the sprint using your definition of done.  My 2 cents: as scrum master you help facilitate that conversation, not do it for the team or the PO.

Thank you Bill. Let me give it a try.

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.
Jul 21, 2021 • edited

You change your process to a proper sprint/scrum process.

If an issue is not "done", the team are not supposed to get any "credit" - the whole point of it is that you measure "done" vs "committed".  If it's not done at the end of the sprint, it's not done.  That's it.

On your specific questions:

1) The data is not wrong - your "definition of done" seems to be "PO has completed/signed off review".  If they're not completing it by the end of the sprint, then either change the definition of done to be earlier (maybe "ready for PO review") and take the PO review out of the workload, or accept that they're not working as part of the team and their work is separate.  (Or tell them off for not doing the job properly, as items are supposed to be completed during a sprint)

2) That's correct, it is loaded, the team still has work to do (remember the PO is a part of the team)

Ok, so the first option here is the right way to do it, but there are other things you could do

1) Adjust the process so that the PO understands that the review needs to be done for the team to burn-down

2) Accept that the PO review is actually not part of the sprint, and remove that step from the board, so that "ready for review" is your "done"

3) Do 2, but with the PO still included.  On moving the issue into "ready for review"/"one" column in answer 2, automate the creation of a "review the linked item" task assigned to the PO, automatically at the top of the backlog, linked to the item they should review, and ready for the next sprint.

AUG Leaders

Atlassian Community Events