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)

First demo and retrospective meeting

Today we did the first demo (sprint review meeting) of the functionalities developed so far. Unfortunately this morning when we arrived there was a bug on the demo server (we updated the last code just before leaving the evening before) , we fixed it before the meeting but we choose to do not show at all the user story “search the arranged trips” even if in any case it was not done. During the demo we found a problem on the story “search travellers” so our Product Owner decided to do not validate the story. There was just a little bug that we fixed in one minute in the afternoon but the impact was declared not acceptable to consider the story as done.

The afternoon was dedicated to the sprint retrospective meeting where we identified and analysed the points that should be done better and we put some new actions for the new sprint. The main points are related to:
– Test process
—- do a brainstorming session to identify the test at the start of the sprint
—- the person that write the tests is not the same that execute the tests
—- verify a story at the end by someone in a challenging way
– Done criteria
—- be more precise on the done criteria with more interaction between the team members and the PO

%d bloggers like this: