Most Common Learnings from Sprint

Date: 03/10/2019

PLEASE READ AND THINK ABOUT THESE and HOW THEY IMPACT your future team behaviour.

1. The need to keep in touch with team members more frequently to share information, plan and solve problems. This increases shared understanding of what to be working on, how to work together, the PO's expectations and the technical solution.

   We discussed the extra richness and immediacy of feedback from body language when meeting face-to-face. Remember the class exercise!

2. The need to keep in touch with the PO more frequently to ask for clarification and explanations of user stories as well as get decisions about the order of features to work on. The faster you get feedback to test your understanding and ideas of the product increment the less likely you will make something that is not what the PO wants/needs, which reduces re-work. Many made assumptions or imagined what the PO would want without checking with him and ended up spending time on functionality that was low priority (e.g. logon).

   We discussed a strategy to force a decision if the PO is unresponsive, rather than waiting and doing nothing.

   We discussed how the PO's world and language are different to yours and you are quite likely to misunderstand are assume incorrectly, so frequent verification and validation of your ideas are a good idea to mitigate this risk.

3. A user story is not "Done" until it has successfully passed all unit tests (responsibility of the Developer), and all user story conditions of satisfaction (team responsibility with PO input). You should ensure you have written and checked UNIT tests at the code level and Conditions of Satisfaction at the functional (User story) level in Sprints 2 and 3.

4. Many teams went through the motions of planning Poker to forecast the effort of user stories but were uncertain of the team's capacity (velocity) so ended up working on whatever looked easy until the sprint ended. We talked about how this was HIGH RISK.

   The idea is to spend enough time probing into the detail of the tasks needed to implement enough user stories for the next sprint so you can forecast their effort with some confidence. (Many teams in industry think 2-3 three sprints ahead). You should keep the data on how long things took to do (at the user story level) so that this can be used to improve your estimate of your team's velocity for the next sprint.

5. Some teams did not feel they were working as a team, but a set of individuals who went off and did work separately. We Discuss how this was HIGH RISK and not very motivating. The need to keep in touch frequently and be together and get familiar with each other apart from this work were discussed. Working together can be motivating, energising and productive if people are empathetic, work at it and understand each other. Be a bit playful and have fun!

6. The retrospective is about "inspect and adapt" (reflect and plan change) the way the team works together (not the product). It should result in a list of 2-3 practical things for the team to try in the next sprint and how you will know if they worked or not. Whether these worked or not will be discussed in the next sprint.

Action these learnings in Sprints 2 and 3. If you keep doing the same, you will get the same!

Happy learning!
Jim