Sprint 4 – Retrospective Meeting

Hi all, sprint 4 is finished! Just after the demo (sprint review) we have started the retrospective meeting trying to go faster to do also the sprint 5 planning meeting in the same day. For the retrospective meeting here the agenda we have followed:

– Timeline of sprint 4
– “Well” and “To be improved” items
– Consensus on items found
– Actions to take for next sprint

Below a description for each point.

– Timeline of sprint 4

Sprint 4 – timeline

This time we have time-boxed this part to 5 minutes only. Normally we start we this “timeline” view of the sprint to show visually the main facts that happened during the sprint helping to remember maybe impediments or difficulties we have faced during the sprint.

– “Well” and “to be improved” items

Sprint 4 – “well” and “to improved”

In this part of the meeting every team member including the PO takes 10 minutes to write down things that go well during sprint and things that instead should be improved. When everybody has finished, every team member tells what he/her have found writing them on the whiteboard (Normally I’m the official writer 😉 ).

– Consensus on items found

Sprint 4 – vote for items found

After the definition of the “well” and “to be improved” items, every team member takes 5 small faces representing him/her and put them near the points he/she consider the most important for the next sprint.

For this sprint the most voted “to be improved” points have been:
– The late validation of PO on user stories
– Risks linked to some user stories not taken into account
– Continuous integration platform
– UI dependency and small knowledge about UI flows
– Test scenario for new PTRs (problem) found

– Actions to take for next sprint

Sprint 4 – actions definition

This is the last part of the retrospective meeting and it consists in defining actions for the next sprint to solve the “to be improved” items chosen before. In particular for the next sprint (sprint 5) we have created the following actions:

1. Inform suddenly the PO and fix the time limit of validation to the day after (late validation of PO on user stories)
2. Take into account risks to prioritize user stories (risks linked to some user stories not taken into account)
3. Schedule meetings with NRE team to follow-up the process to put in place the continuous integration platform (continuous integration platform)
4. Add in the technical documentation the UI flows (UI dependence and small knowledge about UI flows
5. Update QTP and QC tests taking into account the PTRs scenario (test scenario for new PTRs found)