Skip to main content

Testing

Last post 02:50 pm October 27, 2022 by Thomas Owens
2 replies
07:32 am October 26, 2022

In the team I work in we've had a couple changes and adaptions ex. UX parallel work. I made the decision to create a "User Story Lifecycle" in order for the team to get an understanding of- when and where a Requirement turns into a User Story and when and where UX design steps starts and being handed over to developers. 

Now I have come to the understanding that UAT also goes a bit parallel or un-synchronized in our Sprints.. We have BA's and PO that tests functionality, system/code testing we have Agile testers in the dev. team (also automate testing as well) but now I have a question, is there someone here that have a good flow for UAT? Is this something you can exclude from Sprints and handle "outside" of the Sprint? Or can this be handled parallel in some way? 



I tried to change the length of the Sprints to have an additional week for testing, however in my view I believe that a four week Sprint is too long for my developers since I want to keep the phase up and not to have to long gaps 



Can someone share how you are handling UAT in the process?



Thank you :)

Corinne


04:51 pm October 26, 2022

I tried to change the length of the Sprints to have an additional week for testing, however in my view I believe that a four week Sprint is too long for my developers since I want to keep the phase up and not to have to long gaps 

There's your problem right there. You've taken a workflow and used it to waterfall a Sprint. This is a very poor risk control strategy, as you can see.

Don't treat testing as a "phase". Limit work in progress at each station where value is added, so user stories are completed early and often. It isn't necessarily the workflow that's the problem here, but rather the policies which are (or are not) in place and the team's failure to collaborate in support of them.


02:50 pm October 27, 2022

I've yet to see a good way to incorporate a UAT into a Sprint. The biggest problem is that a true UAT must be done by a representative set of end-users (or sometimes customers) of a system. Even if the Scrum Team or the broader product development organization that the Scrum Team is part of is a user of the system under development, they don't offer enough of a representative sampling to make an effective UAT. Therefore, you have dependencies outside of the Scrum Team on starting, communicating feedback about, and concluding the UAT activities. There's no guarantee that the people who will be doing these things can work on the Scrum Team's Sprint cadence.

Instead, I've found that the Scrum Team's Definition of Done and other practices should enable a smooth UAT that doesn't result in the inability to accept the product Increment. The team should expect feedback, but if the feedback is that the product is in a state that cannot be used, the team should treat that no differently than issues with the product reported by end-users in the field. I find it helpful to review any significant UAT issues, perform root cause analysis, and address those with improvements to ensure that the Scrum Team is able to fully satisfy customer and end-user needs and expectations.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.