Involving Stakeholders in acceptance tests during Sprint

How is this handled in Scrum?

@Mohit Joshi, There is nothing in Scrum that says "this is how" it should be handled. There is guidance that helps you get there.

How is the testing conducted during the Sprint to declare an increment "done"? Are the tests performed only by development teams enough to state the increment as done and releasable?

Testing and quality checks should meet the Definition of "Done" in order for the Increment to be considered Done and potentially releasable.

Since stakeholders are not allowed to attend any meetings except "Sprint Review" that occurs after the increment is ready, what if the Scrum user part of the review meeting doesn't like the increment or it is not as per the expectation or with bugs not identified by development teams?

There is nothing that stops the stakeholders from interacting with the Scrum Team or its Development Team during the Sprint if it makes sense to do so. The Sprint Review is a formal opportunity to do this, in case if this couldn't be done before. If there is clearly defined acceptance criteria for the Product Backlog Items and the Increment as a whole meets the DoD, then how would there be bugs? If there are bugs, would you consider that as meeting the acceptance criteria or DoD?

Shouldn't this review occur before declaring an increment releasable?

During Sprint Review, isn't that what the Scrum Team and stakeholders do? At Sprint Review, the Increment should be Done and be in a potentially releasable state. Does not mean that it has to be released.

Hope this helps.

How is this handled in Scrum?

You haven't mentioned a "Definition of Done" even once. How important do you think a DoD is, and how closely ought it to reflect genuinely releasable? What part should the Definition of Done play in inspection and adaptation, and how might it be inspected and adapted itself?

How to perform testing is determined by the Development Team. The Scrum Guide states that "no one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality". I would expect that the Definition of Done would be explicit about the amount and type of testing that would be required for an Increment to be considered "done".

The idea that "stakeholders are not allowed to attend any meetings except Sprint Review" isn't correct. Scrum only defines 5 events - The Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. There is no prohibition from people outside of the Scrum Team from attending the Sprint Planning or the Daily Scrum. In fact, the Scrum Guide puts the responsibility of ensuring that outside attendees do not disrupt the Daily Scrum onto the role of the Scrum Master, so there is some recognition that outside stakeholders may be in attendance. There is no strict prohibition on outside attendees to the Sprint Retrospective, having people from outside the Scrum Team could be detrimental to achieving the goals of that event.

The idea that the Sprint Review "occurs after the increment is ready" is also not fully correct. The Sprint Review happens at the end of the Sprint timebox. Over the course of the Sprint, the team may have produced many potentially releasable Increments. The Sprint Review is a designated time to get all of the relevant stakeholders together to not only look at the work that has been done, but to make adjustments to the Product Backlog and adapt to the changing environment.

There is nothing that would stop the Scrum Team from involving stakeholders at other points in the Sprint. This could come in many forms, depending on the context that the team is working in. This could range from demos of work to obtain feedback to putting a potentially releasable increment into a test environment for sample use, and either could happen more frequently than once per Sprint at the Sprint Review.

Personally, I do not like a Definition of Done that requires involvement of anyone outside the Scrum Team. This isn't always possible, but the more that the Scrum Team can do on their own, the easier it is for the team to control their own destiny. If you are dependent on outside stakeholders to get work to "done" and that stakeholder is not available during the Sprint, you may not be able to get anything to "done". That can not only be demoralizing, but also hamper the team's ability to improve their way of working.

Thank you Steve, Ian and Thomas for your inputs.

While I understand "Definition of Done" should capture what it means to state an increment to be complete (including work, testing and quality), empowering the development team alone to manage the Sprint backlog & the resulting increment doesn't make sense to me.

You mentioned Scrum allows people outside of Scrum team to attend the Scrum events, what I read in Scrum guide is otherwise. There is no formal or informal interaction mentioned in Scrum (while in reality I am sure it is quite possible). So, in one organization it maybe okay for stakeholders to attend daily scrum, while in other they are not part of such meetings. Adapt it the way it works for the organization.

Another example is the Sprint backlog - the guide state once the Sprint backlog is decided in Sprint Planning and the Sprint begins, it shouldn't change. On the contrary, one of the open assessment questions state (the correct answer to be) that during the Sprint only the development team can change the Sprint Backlog after learning more about the items (re-negotiate with PO). So the Sprint backlog can indeed change. I find this contradictory.

I guess that's my main disconnect - I find the guide to be vague, leaving things open for interpretation instead of defining them. Everything is like how it "should/could be" while no "must be". 

Having said that, maybe I need to read more on Scrum and interact more with those who are practicing it in real world to understand the benefits. I am learning more on this topic in preparation of my PSM certification and hopefully it will clear few grey areas for me. Still trying to put my head around it !!

the guide state once the Sprint backlog is decided in Sprint Planning and the Sprint begins, it shouldn't change.

This are the 3rd and 4th paragraphs from the Scrum Guide section that describes the Sprint Backlog.  

The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum. The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.

As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.

I don't remember where the Scrum Guide says that the Sprint Backlog can not change.  Could you point that out?

You mentioned Scrum allows people outside of Scrum team to attend the Scrum events, what I read in Scrum guide is otherwise. 

These are statements from the Scrum Guide.

Scrum Values

The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work. 

Sprint Planning

The Development Team may also invite other people to attend to provide technical or domain advice.

Daily Scrum

The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting.

Sprint Review

During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. 

Attendees include the Scrum Team and key stakeholders invited by the Product Owner;

All of these indicate that there is interaction outside of the Scrum Team. In fact, it is valued and encouraged on many occassions.  Notice that exerpt from the Daily Scrum mentions that outside individuals are prevented from participating by the Scrum Master but it doesn't say anything about inviduals not attending.  In the section describing Scrum Theory there is section on Transparency.  In that section it says 

Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen.

Notice the word "observers".  That would be individuals outside of the Scrum Team that are observing or taking an interest in the work that the Scrum Team is doing.  Again, outside interaction is encouraged.

empowering the development team alone to manage the Sprint backlog & the resulting increment doesn't make sense to me.

Again, going to the Scrum Guide for statements.

Scrum Values

Scrum Team members respect each other to be capable, independent people.

Scrum Team

Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.

Development Team

 A "Done" increment is required at the Sprint Review. Only members of the Development Team create the Increment.

They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;

Sprint Backlog

The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a "Done" Increment.

As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.

The Sprint Backlog identifies the work that will be done to create the increment.  The increment is the cumulative result of multiple Sprints.  The Scrum Team respects each other to be doing the correct thing.  There are 3 roles in Scrum and the Development Team's responsibilities are to turn Product Backlog Items into functional units to be delivered to the stakeholders in an incremental fashion.  If Development Team was not solely responsible for the Sprint Backlog and increment, how else would they be capable of their role's responsibilities?