A really helpful artifact in Scrum is the whiteboard. The whiteboard is one of the main responses of Scrum to the transparency principle (but not the only one). And why I am saying this? Because, it is the place where the development team will show to the rest of the organization the progress and state of its sprint backlog.
There are several things that can be written down in a whiteboard, but the general structure will be a table with a column for each one of the following states:
- To do: User stories (and tasks) that make up the sprint backlog.
- In progress: Stories in which the dev team is working on in this moment.
- Ready to test: stories that have been worked on, and are ready to be tested.
- In test: stories that are currently being tested (by members of the development team, usually QA testers).
- Done: stories that meet the ‘Definition of Done’ agreed by the Scrum team, and consequently, can be accepted by the product owner as done and ready to deliver.
Notice how ideally, QA testes will be responsible for moving the state of the stories from ready to test to done. And they will do that based on the Definition of Done of the team. The Definition of Done could be different across teams, but has to be enough to make a product or a certain feature releasable.