Inspection of DoD/AC

Have a read of the Scrum Guide and check who is accountable for instilling quality by meeting a Definition of Done. That will tell you who needs to verify it.

Once it is satisfied, what is there to accept? Wouldn't the imperative be to release a Done increment, and to gain empirical feedback without delay?

Problem 1: Who in practice verify DoD?

Case: We have some ACs, DoDs, we do sprint to deliver increment and we are close to finish the sprint. There are some USs and they are 'finished'. In this flow who and when is exactly expected to check against ACs and DoD?

My understanding: is that QA person (developer) got notified e.g on visual board that task was moved to "testing" state and it's signal for QA person to check against all AC and move it to e.g state "Waiting for PO approval" so PO can accept the work. What about DoD - in practical world is it as well something that QA should do and test against?

Your understanding is based on a particular team's structure and tools. A team that is using the Scrum framework may not have acceptance criteria, a "QA person", a "visual board" or any other method of sending notifications, or a "testing state" for units of work. These are implementation details - some I would consider good or useful practices, others not so much.

The Definition of Done is a commitment by the Developers. The purpose is to make it clear (or, transparent) what it means for Product Backlog Items to be Done and therefore an Increment to be created. Generally, no one needs to verify that the Definition of Done has been achieved. Developers, acting as professionals, are accountable for ensuring that each Product Backlog Item adheres to the Definition of Done when they say it is Done. If there are specific actions, including checks or reviews, it would be up to the Developers to define them.

Problem 2: How to review/accept the done increment during sprint review

Case: We delivered 5 USs, there is sprint retrospective where PO is inspecting done work but this meeting is attended by important stakeholders as well. So now devs are presenting 5 USs but it turns out that 1 was missunderstood, 1 was done but not on the right quality so is declined, 1 is done according to dev but it didn't pass AC (so is not done), rest are accepted.

How PO should act in this review/accepting the work? The first work that is missunderstood was just assesed as not accepted as it's just wrong piece of software developed - quite clear. Second work is not on right quality but how in practice is it assesed by PO (It links with previous problem)? Third has not passed AC so is it even presented, how to deal with it?

What about stakeholders watching some technical disscussion about passing ACs or some quality matters like loading page within 15 sec?

My understanding: I don't want to discuss technicalities in front of important stakeholders so I splitted sprint review into 2 so I have 'Internal Sprint Review' where work is accepted from technical perspective and there is space for technical discussion and there is normal 'Sprint Review' with prepared presentation, videos etc. so it's smooth and not technical.

Is my solution bad? Any other ideas or maybe Im wrongly conducting this ceremony?

The Sprint Review is not a place for anyone to accept the work, nor is it a gate to delivering value. The Sprint Review is a place for the Scrum Team(s) working on a product and the key stakeholders of that product to come together, look at the work that has been done since the last Sprint Review, come to an understanding of the current state of the environment, and identify the next most valuable step(s) to take to deliver value.

The Product Owner is a member of the Scrum Team and the Scrum Team should be working closely throughout the Sprint to ensure that the work being done is what is needed by the stakeholders. Consider the agile principle of business people and developers working closely every single day. On top of this, the focus of the Sprint is on the Sprint Goal and not the delivery of specific Product Backlog Items. This means that the focus of the Sprint Review should be on if the team accomplished (or failed to accomplish the Sprint Goal) and a check on the Product Goal.

If the team members, especially the Developers are committed to and accountable to the Definition of Done, and the whole team, including the Product Owner, are working together every day, then there should not need to be a need to accept work. Through the act of refinement, planning, and the delivery tasks, along with collaboration, the work will be done right.

Problem 1: Who in practice verify DoD?

The Scrum Guide says the Developers are accountable for "Instilling quality by adhering to a Definition of Done;"

QA Engineers are also the Developers - per Scrum Guide: "Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment"

Problem 2: How to review/accept the done increment during sprint review

There is no concept of "accepting" the increment in Scrum Guide. 

The Scrum Guide says "The moment a Product Backlog item meets the Definition of Done, an Increment is born"

The DoD must be transparent to everyone involved. This transparency and trust that the developer adhear to the DoD should be sufficient. 

During the Sprint Review the Increment is inspected but not with the purpose of accepting it. The purpose is to get everyone on the same page on what has been accomplished in the Sprint. So, that the Scrum Team and the stakeholders can adapt properly for the future.

Right! I confused accepting the work by PO as a (could) point in DoD for example rather than scrum obligation - my bad here. I did a little bit of too much overthinking here instead keep it simple.

I understand that devs should take care of all the quality which means adhering to DoD etc. So from your practical experience - how to approach the last day of sprint? Let's say some stories didn't meet ACs so we decide to move them to the next sprint etc. as developers are responsible for the sprint backlog they are the one to move it on our visual board, correct? I'm lacking some best practices how to smoothly handle those situations. I feel like my idea to have meeting so called internal sprint review where we spend 30 mins to ensure board is updated and reflect reality and move things back to product backlog that were not finished is quite okay approach. It's held instead of daily in the last day so it happens 10:00 and then 10:30 we have sprint planning.

If it comes to the sprint review right I understand perfectly that meeting is to hear feedback, share what was done and review it together. Any practical tips how to engage stakeholders or how to conduct session when everyone participate or can share their feedback? Something more than just asking about the feedback after the presentation?

Thanks everyone for answering!

@Thomas and @Jacek have given you very good detailed explanations so I'm not going to add on. 

@Ian asks a good question that should prompt you to explore and learn on your own.  But I am going to build upon one thing that @Ian said.

Have a read of the Scrum Guide ...

From the description you give, it doesn't seem like you have.  There are so many command/control statements in your description that even if you have read the guide, you should read it about 10 more times.  No where in the Scrum Guide will you see that it states someone "accepts the increment" or that compliance to the Definition of Done is validated.  Nor is there anything listed about any one person that has the authority to rule the Scrum Team such as splitting the review because they did not want something uncomfortable discussed in front of stakeholders. There are no "gates" defined where work is handed off across disciplines, and there is no mention of any kind of boards.  Your implementation of Scrum is not using the Scrum framework as defined in the Scrum Guide.  It may use some of the terms but that is as close as it comes.  True, many companies will use boards of some kind (physical or electronic).  That is a very common practice but they usually track a workflow and are not used for hand-offs. 

Is my solution bad? 

In my opinion, yes it is.  You are purposely inhibiting the transparency that is needed in Scrum.  You are building a system where each review is a sales presentation instead of an open discussion about the valuable increment created and how to move forward from that point. 

I would hope that the topic of that one story that was "misunderstood" comes up in your Sprint Retrospective.  There is an opportunity to learn how that happened.  The Product Owner is accountable for ensuring that Product Backlog Items are understood by everyone.  And if the Developers are interacting with the Product Owner on a continual basis, I believe it would be really difficult for this type of situation to occur.  

  In the past years there were plenty of discussions about verification of DoD, and accepting the increment; I have seen some actual tutorials stating that Product owner can allegedly "reject" increment" if he or she does not consider it to fit Definition of Done...  

Then, in 2020 edition of Scrum guide very interesting phrase appeared (may be it was present in previous editions, but I don't recall it)

Please allow me to quote:

The moment a Product Backlog item meets the Definition of Done, an Increment is born.

 

In my understanding(and please correct me if I am wrong) it means that Increment does not NEED ANY ADDITIONAL HUMAN intervention to be born, except for actual work of the developers who work on PBI

If PBI and DoD are described correctly, and if the described item is deemed completed by developer or developers, Increment is born, disregard of what Product Owner, Scrum master, the rest of the firm or organization think about it

Product owner can of course hypothetically refuse to release increments to the market, but such an antagonizing step means that there are deeper problems hidden within a team, and need to be addressed.

What to do if Stakeholders are not happy with an increment is a separate question. In most cases it means that definition of Done was not shaped properly. It can be because Product owner didn't communicate the Product backlog and Product goal properly, or stakeholder feedback and organisational standards were not properly accounted, or for many other reasons, including bad performance of Scrum event.

Retrospective must be a good to address it, including updating DoD

  To end with please remember that Definition of done is living and interactive commitment to the Sprint artifact (Increment) which can be changed when need, any time during the Sprint  

@Daniel I am speaking about practical approach and processes that can support good understanding of the scrum, let me share something with you:

The Scrum framework is purposefully incomplete, only defining the parts required to implement Scrum theory.

As I said as in my team it's part of the DoD that PO accepts each PBI, I forgot it's not a mandatory part of the scrum but only applied to this particular team. 

I know that there is nothing about compliance to the Definition of Done is validated and THAT'S EXACTLY THE REASON I am asking because it just appeared that it wasn't fulfilled on certain level and I was wondering how I can support adhering to it.

There is difference between uncofortable discussion and going in prepared which makes a great impression to some stakeholders. I am absolutely increasing transaparency in the team thanks to this meeting so they can clearly understand what is going on with the planned work, whether it should be done that way or even needed is another story - maybe once the team is more mature and understands the flow better it won't be needed as such inspection would happen on daily basis.

Obviously there nothing about gates, boards or anything like this nor there is about story points but people are using them as this is considered good industry practice and are basic functionalities of any top tool like JIRA or Azure DevOps? You sound exactly like someone that read scrum guide 100 times but never been part of a single scrum project and faced some reality problems or been limited by some company coinstraints. I recommend you familiarizing with bad stances for Scrum Masters as I strongly feel Scrum Police attitude. 

@Nicholas I think you got it right but we have to remember about DoD's where interaction like "accepted by PO", "accepted by UX" is required (of course it happens before meeting the DoD so technically you're still right)

What I meant is that I have new team 8 people that just started working with each other and they yet tend to forget about small things like following the established process so I wanted to somehow support the process of ensuring quality like meeting DoD but maybe only support needed is to keep guiding them how to cooperate on daily basis with PO and others so everything is on point.

The Scrum guide was updated in 2020 towards more flexibility of DoD and giving developers more free hand for a reason. It was because "test left", CI/CD, and DevOps communities could not use Scrum because of long, week to month Stop/Switch system and too much arbitrary power on PO side

So it was adapted the way which gives Developers more power and freedom: allowing testing early in the Sprint, allowing increment and even release anytime during the Sprint, so customer feedback would come before Product backlog refinement if the team is practicing DevOps, and clearly giving developers the power to decide when increment is ready, without any need of acceptance from Product owner or anyone else

Of course if acceptance from PO is acceptance by UX is an organizational standard, then it should be part of DoD, but in that case it's a good idea to use Sprint review to ask stakeholders WHY is that necessary, because it makes deployment less efficient.

It is a good idea to work with PO discussing the efficiency of his actions in regards of "rejecting" the items too.

Let's say some stories didn't meet ACs so we decide to move them to the next sprint etc. as developers are responsible for the sprint backlog they are the one to move it on our visual board, correct?

Per Scrum Guide: "If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration"

So, basically, each PBI, which doesn't meet DoD goes back to the Product Backlog. Of course, it might be later decided to put it into the following Sprint, but it should not happen automatically without any discussion.  When closing the Sprint in JIRA there is an option to move the PBIs either to the next Sprint or to the PB. I think this option of moving to the next Sprint is unfortunate since it provokes the behavior of 'zombi scrum' where PBIs are just being moved over and over again to the next Sprints without consideration.

So from your practical experience - how to approach the last day of sprint? 

From my experience the key point is to make sure everyone understands Scrum correctly - the Scrum Team, organization, and stakeholders. Then working with the Scrum Team to establish good practices, which are aligned with the Scrum Guide. It is important not to force the processes but work them out with the Scrum Team by asking proper questions if you see they go in the wrong direction. Most of cases it is a step-by-step evolution from the existing processes. At least I prefer such an approach, although I know some people prefer more stormy approaches. 

Again, the key is to have everybody get a good understanding of Scrum.

Per Scrum Guide: "The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization."

 

Any practical tips how to engage stakeholders or how to conduct session when everyone participate or can share their feedback? Something more than just asking about the feedback after the presentation?

I think the key point is identifying the proper Stakeholders, which are truly affected by this product. If there is low interest in Sprint Review it is often a sign that the gravity is somewhere else. That the 'important' decision and 'important' people work somewhere else together.

@Jacek thanks for sharing but I am seeking for some more practical ways to approach those than just explaining what scrum says as I am familiar with this. 

For the first: I understand concept that it shouldn't go with button to the next sprint and requries discussion, reconsideration and it goes through planning (to avoid mechanical brainless moving) but what I was lacking that last day of sprint happens and I found that my team is lacking some ownership from the developers to manage their board correctly and conduct such a discussion by themself - for me one of important thing is creating and supporting self-management in the way that they can operate as if I wasn't there - so I wanted to guide them initially by creating dedicated space (meeting/reminder) so they learn for few sprints that this is how you should operate instead of joining meeting and it needs to be driven by me or nothing will happen.

For the second: Sorry but I don't feel like you're answering the question - my question is about the very last day of the sprint and how to organize it in smoothest possible way. Being guardian of scrum is of course important but not relevant to the question.

For the third: Again - zero new stuff from the perspective of practical approach. I am seeking for something like oh, try method X for conducting reviews it was really useful in my case. For example tips like in this article

I think my questions/cases were missunderstood I am not looking for basics mechanics of scrum but practical tips and 'how to' in order to increase self-management of the team.

Thanks for the input anyway!

I don't want to discuss technicalities in front of important stakeholders so I splitted sprint review into 2 so I have 'Internal Sprint Review' where work is accepted from technical perspective and there is space for technical discussion and there is normal 'Sprint Review' with prepared presentation, videos etc. so it's smooth and not technical.

Is my solution bad? Any other ideas or maybe Im wrongly conducting this ceremony?

Hello. Just for the reference the ceremony not really a good word.

Those are events, not ceremonies

Anyway, there are few things which are problematic: Its not a good idea for Scrum master to conduct the evets, its a good idea to make sure that they are taking places are time boxes and attended, not acting as  speaker or a chair. In many cases it is good idea to let the event follow its course, correcting only when there is a danger of disconnecting with meaning.

Also Sprint review is NOT A PRESENATION

Increments are also presented, but is a working session where stakeholders and Scrum team discuss the project and figure out what to do next. SO its actually a good idea to discuss technical issues and problems during the event.

It is also might be a wrong idea to use the event so PO will discuss with a team if Increment meets DoD or not, this discussion, if there is a disagreement should have had happened during a Sprint, when Developers had made an Increment, or during Sprint retrospective, because it is an internal business of the team.

I apologize for sounding like the "scrum police" but I did not see your second post before I posted mine. 

For the record, I have a lot of years experience with Scrum and many other agile practices going back to before the Manifesto for agile software development was created.  I have even worked with companies to build their own version borrowing from a lot of methodologies, frameworks and such. 

My biggest concern is that you consistently say that you are creating or establishing things.  As a Scrum Master (in the sense of the Scrum Guide) you should not be creating anything.  You should suggest and then have the Scrum Team discuss and react.  This is part of helping them to become more self-organizing. However, since we know that the Scrum Guide does not provide job descriptions or titles, you will need to defer to the job description that your organization has created for the job title you have been given.  More often than not, those job descriptions list a lot of things that would not be considered "right" but we all need to make a living.

You keep saying that you want specific information and not guidance.  Ok, here is how many of the teams that I have been part of (as Scrum Master, Developer, Product Owner, and other job titles) have handled the last day of the Sprint. None of these teams started out with all of this.  They matured into the ability to work this way.  I facilitated, coached, and nudged them along by working on one of the events at a time, usually starting with the Daily Scrum because it is the one that occurs the most and is, in my opinion, a key to self-organizing. 

• Start day with the Daily Scrum at it's usual time.  The Developers discuss any work that they will be doing that day and formulate their plan. This is not any different than the way the Daily Scrum is done every other day of the Sprint. (I will note that none of the teams prepare presentations or need to have any formal signoffs from anyone in the organizations. It is not uncommon for them to be updating code right up to, and sometimes during, the Sprint Review.)
• At the designated time, the Sprint Review will start.  It is a discussion that the Developers facilitate to discuss the work that they did with the Product Owner and Stakeholders that are in attendance.  They may choose to show some of the functionality if it is pertinent to the discussions or someone asks to see it. During the Review, the Product Owner will take notes or directly update the Product Backlog to capture the feedback that is received. Any work that is not completed during the Sprint is discussed, updated and moved to the Product Backlog. 
• Next the Retrospective will start.  The Scrum Team will use various means of capturing topics that they want to discuss using the Sprint as the basis for those topics.  There will usually be 2-3 "action items" that the team chooses to do in order to improve their ability to work as a self-managed cohesive team.
• And then Sprint Planning starts.  By this time the Product Owner has updated the Product Backlog with the feedback received in the Sprint Review and has ordered the backlog as they feel is appropriate.  The Product Owner will discuss those updates and additions with the Scrum Team to ensure that they are fully understood. The Product Owner and the Developers discuss the Product Backlog and come to an agreement on a Sprint Goal that describes the reason for the work that needs to be done.  Then the Developers start to pull items from the Product Backlog into their Sprint Backlog that will satisfy the Sprint Goal.  They will also pull in any extra work that they feel the need to address (often this is tech debt or research needed to further refine items that are in the Product Backlog).  Everyone will discuss the Sprint Backlog to ensure that it is understood by everyone and there is agreement that the Sprint Goal can be satisfied by the items chosen. 
• Next Sprint begins.

Some of the teams chose to spread the events across 2 days to deal with meeting fatigue but others chose to power through them one after another. In the end, they all found a cadence that worked for them. 

If you want me to provide you some specific exercises used in the Sprint Retrospective or techniques for getting the team to become self-organized and self-aware, I'd be happy to do that.  We can hook up outside of the forum because it is a really long discussion that will be needed and there will be some back/forth that not everyone will want to follow. 

A lot has been said already and I learned from these.

I do appreciate  organisations can be incredible political. Sure, explain scrum to them as a first mitigation. I will remove external stakeholders that cannot contribute domain knowledge. Rather include them in the demo session when ready to demo.

...5 USs but 1 was missunderstood...another not on right quality...

This is what scrum is designed to do, to catch misunderstandings quickly (in 1 sprint). From here the team can try to improve. Questions like why did nobody pick up a US is misunderstood? Are people working to much in isolation? Is the PO not always available? Were US description insufficient? Can discuss in non combative environment.  An important question, can the work being done, fit in with another PBI, instead of just thrown out to make an example of the developer?The items that failed quality, discuss if the entire item needs to roll over to the next sprint or if a new PBI be created for the defect? But itt looks like your sprint review is working as designed.

A few thoughts. Is the team trying to take on to much each sprint!? Is the development done in isolation and only presented at the sprint review, thus PO sees it at sprint  review for the first time.Is the environment overly confrontational? Is the team (including PO)  collaborating? I get the impression the company continue doing traditional project management, and  implementing the scrum-guide as fixed rules and commandments. For example sprint review is not a punishment session were work gets rejected. It is a session to align all on were the development is at. What is working and what still needs to be done, and the product backlog is then adjusted.