Accepting the sprint in the Review meeting? And some other Review questions

[Liam Burns]

My company has implemented a new process of having the team be responsible for the Definition of Done inside of the sprint.

In the Sprint Review meeting the PO is shown the work for the first time and they go through each issue in front of the team and then make comments on the issue e.g. "does it work as intended. if not, how? Defect created..."

Reading lots about Scrum this doesn't seem to be the "Scrum" was to do things, in fact a lot of resources explicitly say that having the review meeting as an acceptance meeting is a bad thing and it should be about feedback.

The problem with this is when should the PO be seeing the work? When do we accept/reject a sprint?

We currently don't have the PO testing in a sprint because of a few reasons:

• If a PO is testing during a sprint then the ownership of making sure issues are understood isn't on the team, they could half understand and just implement something and then get an explanation from the PO after they've showed it to them.
• There's also less need for a team to test their own work because they've got the PO there to catch things.
• The PO has a lot of things to do during the sprint e.g. Backlog grooming, meeting clients, if we add in testing during the sprint to this then there may be too much to do.

Again these are all assumptions we have made so any thoughts on these would be extremely helpful.

[Ron Jeffries]

Hello Liam,

On Feb 10, 2016, at 6:42 PM, Liam Burns <li...@wearenova.co.uk> wrote:

My company has implemented a new process of having the team be responsible for the Definition of Done inside of the sprint.

In the Sprint Review meeting the PO is shown the work for the first time and they go through each issue in front of the team and then make comments on the issue e.g. "does it work as intended. if not, how? Defect created..."

Reading lots about Scrum this doesn't seem to be the "Scrum" was to do things, in fact a lot of resources explicitly say that having the review meeting as an acceptance meeting is a bad thing and it should be about feedback.

Yes, that is not the way you do it. Scrum states rather clearly that the Sprint Review is for the PO and team to present the DONE work to the stakeholders. You cannot present work that is not done. Therefore the PO must have accepted the work already.

The problem with this is when should the PO be seeing the work? When do we accept/reject a sprint?

I’d think they should see each backlog item as soon as the team thinks it is done. You don’t accept / reject a Sprint. You accept backlog items. And if you ever ever ever wind up rejecting one, you need to address why the team didn’t understand the requirements well enough to do the job. The usual adjustments are improve backlog refinement (you are doing backlog refinement as a team, right?), improve Sprint Planning, and, most important, agree on concrete repeatable acceptance tests which, if the item passes them, it will be declared DONE.

This avoids the common trope where the PO looks at something that’s done exactly as agreed and says “I don’t like it, it’s not accepted”. The correct thing to say is “That’s as we agreed, it’s accepted. I don’t like it. Here’s the new backlog item to replace or modify it."

We currently don't have the PO testing in a sprint because of a few reasons:

• If a PO is testing during a sprint then the ownership of making sure issues are understood isn't on the team, they could half understand and just implement something and then get an explanation from the PO after they've showed it to them.

That would be inefficient, slow you down, and you’d resolve it in your Retrospective. However, it is inefficient in the extreme, and risky, to test the backlog items after they are done. Far better to have agreed, automated, tests before you even start. (Consider a CSD course to learn some good ways to do this.)

• There's also less need for a team to test their own work because they've got the PO there to catch things.

If you’ve agreed on acceptance criteria, and they’re not met, then it is obvious that the team are screwing up. Because the team are not stupid, they will not screw up. Instead, they’ll make the agreed tests pass.

• The PO has a lot of things to do during the sprint e.g. Backlog grooming, meeting clients, if we add in testing during the sprint to this then there may be too much to do.

Yes, as a rule, the PO will be too busy to do testing. The testing needs to be done by the team, as agreed up front with the PO during refinement and planning. The PO can then quickly check the results and does not need to test anything in detail.

Again these are all assumptions we have made so any thoughts on these would be extremely helpful.

I think you’re a bit on the wrong track but moving toward the ideas above should get you back on track.

Ron Jeffries

ronjeffries.com

I'm really pissed off by what people are passing off as "agile" these days.

You may have a red car, but that does not make it a Ferrari.

  -- Steve Hayes

[Dan Rawsthorne]

Well, the PO is a member of the Scrum Team, so the PO should be seeing the product every day. I like having the PO move the Story to the Done column as a ceremony for each Story as it gets to Done. This can be done at the Daily Scrum as part of "what did we do yesterday" or as the story gets done.

As for testing, verification testing is done by the DevTeam as an intrinsic part of development. It's possible that the PO is on the DevTeam (not wearing the PO hat), so the PO might have the testing skills... but it's not a specifically PO thing. Validation Testing should be its own Story, IMHO...

And, the Sprint is a feedback loop... meaningful feedback from Stakeholders on the Product, and feedback from the Team on process and teamwork. The idea is to improve each (the product and the team) every sprint. The Sprint Review is not about accepting the Sprint or Product Increment - it is an inspect and adapt point. Get feedback on the product, and update the backlog based on the feedback...

Dan  ;-)

Dan Rawsthorne, PhD, PMP, CST
3Back.com
1-855-32-3BACK x323
Author of:
   Exploring Scrum: the Fundamentals
   Exploring Scrum: Patterns that Make Scrum Work
Download our free eBook, Scrum 101: a Pocket Guide

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.
Visit this group at https://groups.google.com/group/scrumalliance.
For more options, visit https://groups.google.com/d/optout.

[Rohan D'Sa]

On Thu, Feb 11, 2016 at 12:42 AM, Liam Burns <li...@wearenova.co.uk> wrote:

Reading lots about Scrum this doesn't seem to be the "Scrum" was to do things, in fact a lot of resources explicitly say that having the review meeting as an acceptance meeting is a bad thing and it should be about feedback.

​I cannot say much more than the revered gentlemen before me already have on this thread, but..

A practical way we've found to work around this is have the person testing the user story verify it with the PO before closing it. In fact, 'PO verification' is the last item in our definition of done. Note that the verification is not a full test, the PO needs to have trust in the team that does its testing, otherwise this needs to be addressed through retrospectives.

This typically happens 3-4 times in a sprint for short periods of time, and in that way the sprint review is just about showing 'done' working software​ to stakeholders other than the PO, and not really about presenting to the PO.

[Chet Hendrickson]

HI,

I would want your team to do, is ask itself What would we do if this is the last Sprint before we go live?

And, then do that every Sprint.  That is what your Definition of Done should be.

chet

	Chet Hendrickson ch...@hendricksonxp.com	Tel 248.345.7258 http://www.hendricksonxp.com