Development and UAT cannot be completed in one sprint to deliver value at the end of the sprint. Reason, UAT is done by the business user. As a workaround, if I try to split this into 2 user stories ; do the development work in one sprint and UAT in another - it leads to some amount of rework and I feel this isn't the most efficient way. What are the ways to handle this ? Saving Changes...
Sort By:
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
By definition (and in the practice) development and testing must not be splitted because at the end of the sprint you have to deliver something working. My recommendation is taking the story and put it inside a sprint where it can be concluded end to end. If because the length of the story you estimate it can not be concluded into a sprint then you have to split the story. But never separate development from testing. Saving Changes...
Bring UAT inside the sprint. Functional/system testers and UAT testers need to start their in parallel. It would expedite feedback gathering for developers. If there is no such metrics like ‘high UAT defect’ is red flag, this approach should serve the purpose. Having modular sized stories/requirements are key. Pushing UAT outside the sprint will create another phase gate, delay feedback gathering, elongate the lead time, wouldn’t have ‘potentially releasable increment’ by end of sprint. Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
May be one of the disadvantages of Scrum and showing what works for small systems may not work for large implementations.
Good practice for large system development was to split development and testing teams and let them compete for the # of bugs found. Very effective on quality. Both teams start from requirements.
Thomas Saving Changes...
Alexandre CostaScrum Master| Integer Consulting - Pictet technologiesLoures, Portugal
I agree with all the opinions given so far, but as a last resort you can consider to increase the size of the sprint, there is nothing in scrum that prevents this.
It can be done because it has been found that the sprint duration does not suit, for example, the size of user stories, or because there are dependencies that require more time to deliver value.
Of course, this decision must be taken carefully and before the sprint begins and it is not desirable to do this for the convenience of the user stories in this particular sprint, but because it is desirable for the entire course of the project, nor is it desirable to switch between sprint durations throughout the project for convenience.
If you think the duration of sprint that was chosen at the beginning of the project is the right one, then you shouldn't even take this argument into account. Saving Changes...
One of the benefits of time-boxing is enabling a short feedback cycle based on completion of a few work items. Completing part of a life-cycle within a sprint is not getting to done.
Alexandre provided one strategy of increasing sprint length, but I prefer to reduce sprint length or do away with sprints entirely and use a continuous flow delivery model.
One way to enable this is to reduce the size of work items further so they can be delivered with a low cycle time.
However, without having a "whole team" of all skills needed to take a work item to done, your cycle times will be long and unpredictable.
One solution for this is to find a way to increase predictable availability of those needed for UAT.
Kiron Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
Why not one set of tests that supports end-to-end testing; unit, functional, integration and acceptance? The tests, automated or not, that come out of an iteration should be candidates for users' validation testing. The product owner is well placed to ensure that test development includes business-level validation. Saving Changes...
