Scrum Sprint Stories in Testing

Question

I am a Scrum Master and have been practicing Scrum in my Organisation. We have now moved on to ServiceNow for development and we are facing issues now.

Issue: We work on sprint->story->task, but, we now have a requirement that my story also needs to be tested by the client (customer/stakeholder) before closing them.I am also acting as a Product Owner, the client is available for approving stories but is not available for Testing.

This is a new requirement as we were having a lot of issues in Customer expectation. We are trying to resolve but keeping Sprint Stories open is not a good option, please suggest.

Answer 1

If you are the scrum master and product owner you are a project manager pretending to do scrum.

The product owner absolutely has to be someone from the client that is empowered to approve stories, prioritize stories, and accept stories as complete. This is necessary because it forces the client to be involved in the process and there expectations should more closely match because they are approving and accepting what happens and when. If your client isn't willing to be involved at this level its really hard to do scrum.

The best ways to help manage client expectations are continue to encourage them to get at least one person more involved, and to ensure every story has a solid definition of done that both you and the client understands.

If the problem of clients not being available to test is more of a timing issue rather than clients not willing to spend any time at all, you can run "QA sprints" in parallel with development sprints. It is definitely more process heavy and ugly, but it can be made to work. Essentially you would close sprint 1 and move it to a QA/Staging environment and start work on sprint 2. During that time your client can test sprint 1 and they can create new stories to fix problems they find, they can also decide if these things are capable of waiting to be done in sprint 3 or if something should be taken out of sprint 2 to make room for it. When you are ready for a release you would likely have to stop development and have a "release sprint" focused focused on building the release and fixing any problems with the previous development sprint.

Answer 2

we were having a lot of issues in Customer expectation

Finding the root cause of this is the best way to improve. Symptoms can be treated but improvements will be minimal or nonexistent. Were the desirements poorly understood? Were acceptance criteria lacking? Were the Increments not Done? Is the Scrum framework understood by all parties involved?

Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.

At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.”

The Scrum Guide

The customer does not define the Definition of Done.

Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment The Scrum Guide

Customer testing cannot stop an item from becoming Done.

A Sprint Review is held at the end of the Sprint to inspect the Increment The Scrum Guide

Once the Increment is complete, it should be reviewed with the customer. Feedback from this event can create new items in the Product Backlog.

Answer 3

Simply, your backlog and especially your sprint backlog should only include items that can be completed by your development team. That's development team in the Scrum sense: i.e., anyone and everyone who is part of the Scrum team. That could be actual developers, QA, infrastructure admins, DBAs, etc. The point is that it's these folks who will actually be doing the work and, more importantly, it's these folks who are doing the sprint planning and dailies.

Additionally, your Definition of Done should only include items that the development team is capable of providing. A PBI is done when your development team has completed all the work on it and met the agreed upon Definition of Done. Since the development team alone is responsible for driving the sprint and getting all the PBIs to "Done", there cannot be any external influence in the Definition of Done.

Given those two things, stakeholder testing and approval should not be part of your Definition of Done or part of your sprint. Rather, it would be part of your release planning. One of the most brilliant aspects of Scrum that people seem to just totally miss is that sprints don't have to be followed by releases. The team delivers an increment of done, working software that is potentially releasable, but there is no condition on when or even if it has to be actually released. Where people started messing up in Scrum generally comes in here. They start trying to add all sorts of conditions on whether something is "done" or not for the purposes of the sprint, based on arbitrary conditions on releasing the software.

When there's external forces involved in deciding if a PBI is done or not, you're going to end up missing your sprint targets every single time. Simply, you don't control stakeholders, and it's impossible to assure that they will review the increment before your sprint is over. As a result, you'll end up with all your PBIs sitting in the "in progress" column when the sprint ends.