Consider what it takes to completely finish a story in our organization.Demo requirements were metUI design finalized (layout, styles, fonts, controls, colors, etc...)User text finalized and mistake-proofedAll text translated to Spanish, Germal, Italian and French.User manual updatedAll bugs deemed by PO as need fixing for release were fixedDocuments for FDA updated (SRS,STD,STP,STM,UFMEA, DFMEA, SDD, installation)Requirements were written and approved by POUI spec was written and approved by POAll tests (final acceptance and integration) written/updated and executed - synced and agreed with test managerAll FAT tests were approved by QPERegression testing was doneCode was reviewed and documentedUnit tests were written and executed - synced and agreed with software manager.Refactoring, if needed, was done - synced and agreed with software architect.Design was documentedInstaller was updated (If needed)With so much work needed to fully complete a story, the team stops being nimble and it becomes more difficult to try out new features quickly. As far as I see there are 3 ways to solve this problem:Do more Spike stories which don't meet the Done definition but serve as quick prototypes to gather feedback from users.Get feedback from users all the time during the Sprint rather than at the end of it. So half-way through the story you could already gauge what users think of the story and quickly adapt before doing all the heavy stuff (translations, user manual and such).Relaxing the Done definition to require just basic testing and bug fixing. This way the team won't have a potentially shippable product at the end of the Sprint, but it will be very quick to try new features and technical innovations without suffering from the burden of documenting everything, writing user manual, doing design polishes, etc...Which option would you pick and why?Thank you.
Scrum: relaxing done or using spikes?
scrum