Consider what it takes to completely finish a story in our organization.
- Demo requirements were met
- UI design finalized (layout, styles, fonts, controls, colors, etc...)
- User text finalized and mistake-proofed
- All text translated to Spanish, Germal, Italian and French.
- User manual updated
- All bugs deemed by PO as need fixing for release were fixed
- Documents for FDA updated (SRS,STD,STP,STM,UFMEA, DFMEA, SDD, installation)
- Requirements were written and approved by PO
- UI spec was written and approved by PO
- All tests (final acceptance and integration) written/updated and executed - synced and agreed with test manager
- All FAT tests were approved by QPE
- Regression testing was done
- Code was reviewed and documented
- Unit tests were written and executed - synced and agreed with software manager.
- Refactoring, if needed, was done - synced and agreed with software architect.
- Design was documented
- Installer 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?