Effective Sprint Review and Retrospective Best Practices

sprint review and retrospective n.w
1 / 9
Embed
Share

Learn about the best practices for conducting Sprint Reviews and Retrospectives in software development projects. Explore the importance of stakeholder involvement, team reflection, and overcoming communication barriers for successful agile implementation.

  • Agile Practices
  • Sprint Review
  • Retrospective
  • Communication
  • Software Development

Uploaded on | 0 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.

E N D

Presentation Transcript


  1. Sprint Review and Retrospective David Ferry CSCI 5030 Principles of Software Development Saint Louis University St. Louis, MO 63103 1

  2. Sprint Review Demo to project owner and stakeholders Happens at the end of each sprint Open to anyone with a stake in the project Great opportunity to satisfy power holders Process: 1. 2. Demo each completed sprint backlog item Product owner decides which backlog items are done According to acceptance criteria and definition of done Items are discarded or sent back to product backlog All tasks are discarded, regardless of done Stakeholder feedback Anyone may add new product backlog items Anticipate the product backlog grows over time as more ideas added, but PO organizes the backlog 3. CSCI 5030 Principles of Software Development 2

  3. Sprint Retrospective A team meeting at the end of each sprint The sprint review is a chance to inspect product The retrospective is a chance to inspect process Remember: agile is a dynamic, not defined, process Where teams become learning teams and adaptive The business environment is always changing, a team that doesn t adapt will eventually become sub-optimal or obsolete The team must continuously reflect and change itself Two or three basic questions: What went well? What could be improved? What did we learn? CSCI 5030 Principles of Software Development 3

  4. Retrospectives are Hard Computing is easy people are hard! It s hard to change habits It s hard to change processes without hurting people s feelings It s hard to stay focused on group welfare rather than personal welfare It s hard to come to compromise and negotiate It s hard to stay positive and not make personal attacks But communication is how we learn and grow. The retrospective might be the distinguishing feature of Agile and Scrum versus other methodologies. CSCI 5030 Principles of Software Development 4

  5. Barriers to Effective Communication Jumping to solutions Natural urge to start thinking of solutions before a conversation can be had Take the time to understand what the real problems are in an organization Need to avoid band-aid fixes Focus should be on working together towards shared goals Personal status level differences Senior and junior personnel can and should disagree Some members are slow to speak, some are quick to speak Some speak too much, some speak too little Every perspective is meaningful CSCI 5030 Principles of Software Development 5

  6. Scrum Master as Facilitator Goal is to develop team dialogue so team can self- govern Does not intervene directly in the content of a group's discussions Is neutral, does not have personal opinions, encourages group to solve its own Should not reduce group's responsibility for solving its own problems by taking charge Many techniques, e.g.: Safety check Planned conversation flow Silent writing Check out funretrospectives.com CSCI 5030 Principles of Software Development 6

  7. Safety Check People are only candid when they feel psychologically safe, and Scrum relies on self- governance Power/experience asymmetry can reduce the safety of the lower ranked or junior Demographic race/gender/etc. imbalances People feel less safe if they don t believe they will be taken seriously or listened to Bad past experiences can cause hesitation as well Understand group safety and make the safer members aware there is an imbalance with anonymous poll Mitigate imbalance by breaking into small groups CSCI 5030 Principles of Software Development 7

  8. Planned Conversation Resist the instinct to start solving the first issues raised in group meeting Surface level discussion may miss deeper group dynamics that only surface with deeper discussion Not all group members may agree what problems exist Break discussion into four discrete timed phases: 1. Objective What happened during the sprint? 2. Reflective How do we feel about it? 3. Interpretive What does it mean? 4. Decision What do we do about it? CSCI 5030 Principles of Software Development 8

  9. Silent Writing Some group members speak too quickly, too slowly, too much, too little, etc. and are under- or over-represented. Have a 5-10 minute silent period of writing sprint observations on sticky notes. Read and categorize notes publicly, have a conversation interpreting notes and clusters Come to consensus on any notes/clusters that prompt changes and develop a set of actions for each CSCI 5030 Principles of Software Development 9

Related


More Related Content