nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

in review stories moving to next sprint

Agile Curve

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?

Comments

Nic Brough -Adaptavist-

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.

Bill Sheboy

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,
Bill

Agile Curve

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

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.

Agile Curve

Thank you Bill. Let me give it a try.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

agile