We take initiative and ask for forgiveness instead of permission.
By testing and reviewing User Stories the PO gives direct feedback to the team.
Kabisa developers test themselves, write automated tests and perform code reviews on each other’s work. Still manual testing of new functionality by business users is invaluable for the quality of software.
Prepare for success
Decide at the start of the sprint which stakeholder (or the Product Owner) will test a finished story or bugfix. Make sure that this tester is available during the sprint, and the development team knows how to contact the tester.
- Make sure the tester is aware of the goal and acceptance criteria of the story.
- Execute tests manually on the staging environment.
- Developer and tester can interact directly, but when in doubt about the scope, make sure the Product Owner is involved.
Definition of Done
- Any found bugs are fixed.
- If useful, automated tests are added.
- Test results are known to the Product Owner. He can accept the User Story
Real Life Example
During Backlog Refinement, the Product Owner and Development Team split up a user story in two smaller user stories. The scope of the original story was to make the page header of a certain type of web page fully conform the new design. The smaller stories were:
- Being able to add a photo to the page header via the CMS.
- Expanding alignment options for the page header in the CMS.
During Sprint Planning, the Product Owner shared the contact details of the business user that would test the new page header. Only the first of the two stories was taken into the sprint. When the business user tested this first story during the sprint, she reported that the alignment options were missing. Other than that, she was happy with the new functionality. When the developer explained and showed to her that the alignment options were not part of this specific story, she changed the test results in Pivotal Tracker. The developer subsequently marked the user story as ready for acceptance by the Product Owner.