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)

Sprint 4 – Scrum board status

Sprint4 - Board Status

Sprint 4 - scrum board final status

Here you can see our Scrum board at the end of sprint 4. There is still two unfinished user stories (not done). At the top of the board you can see instead the green posts-it where we write the actions coming from the retrospective meetings.

Thinking to solutions

Here an example of how we use the small whiteboard we have in the scrum office. It is mainly used to design the new functionalities 🙂

Sprint 4 – Acceptance tests

Here the part of the scrum board dedicated to our acceptance test ideas for different user stories. Normally these test ideas are written during the sprint planning meeting but they are also updated if new ideas are coming or something changes. The main point having them on the board is that everybody in the team can always know the overall test ideas for every user stories.

%d bloggers like this: