lab06-part1 : Retro Outcome Logging / Review and Plan Leadership Roles / Second CATME.org Peer Eval / Start Design Document

Retro 2 Outcome Logging

• For the experiment you decided upon in your second retrospective, use the metric that you had planned on using to decide if the change brought positive results or not. Log the outcome in the following way

  Retro 2 leader: add Section to team/retrospectives/RETRO_02.md

  ## Retro Outcome Assessment
  
  * A brief description of what your retro 2 experiment was 
  * A brief recap of the metric you planned on using 
  * The outcome according to the metric now that the next Sprint is done (maybe already for a while).
  * Your conclusions based on this outcome. You can decide to cement this change going forward, to modify it (start a new experiment), or to discard it and go back to previous procedures.    
  

Review and Plan Leadership Roles

Visiting your ./team/LEADERSHIP.md file, remind yourselves who took on previous leadership roles for your team, and log anything that may have fallen by the wayside.

For example (if applicable): * Initial Product Owner * First Retro Leader * Second Retro Leader * MVP Peer Eval Leader

Then, discuss the list of roles below and assign one team member to each of the roles.

Several people will clearly be assigned to more than one role. That’s fine, but follow these rules:

* The product owner and the scrum master *may not* be the same person at any time, and
* The retro leaders for each of the three retros in the quarter should be different people.
* No one should take on three roles unless/until each team member has already taken on two.

  If you have a situation where it is impossible to satisfy all of these rules, check with your mentor; they are permitted to authorize exceptions where there is a legitimate need to do so.

Also, whoever is chosen below as the “Design Document Coordinator” will be responsible for copying these roles from your discussion into ./team/LEADERSHIP.md.

Roles to assign

• Product Owner. Together with Scrum Master, leads the Sprint Planning meeting(s) to come Responsible for making sure that the team comes up with a set of user stories for the “final” product that your team will deliver, and marking those stories with a label “final” (just like the label MVP that you used previously).
• Scrum Master. Together with Product Owner, leads the sprint planing meeting(s) still to come. Responsible for making sure that the team comes up with a set of issues for the “final” product that your team will deliver, each tied to one of the user stories. and marking those stories with a label “final” (just like the label MVP that you used previously). Also responsible for holding the team accountable for keeping the issues moving through the Kanban board.
• Testing/QA Coordinator. Ultimately, responsible for making sure that user stories and issues have acceptance criteria, and that these are met before pull requests are accepted into master. If you are doing any sort of TDD or BDD, this person will also mainly coordinate that effort.
• Retro 3 leader. This person will lead the third retro during week 9.
• UX Coordinator. Responsible for the look and feel of the product, and the way that the user interacts with the product. By next week, will have a set of pointers and recommendations for the UI/UX of your products…
• Design Document Coordinator. This person is responsible for the design process documentation started in this lab, chiefly the document pointed to by ./docs/DESIGN.md. By next week (lab07), they should ensure that there is a first version, and will be responsible for updating it throughout the rest of the quarter.
• Deployment Document Coordinator. This person is responsible for the deployment documentation refactored in this lab, chiefly the document pointed to by ./docs/DEPLOY.md. By next week (lab07), they should ensure that there is a first version, and will be responsible for updating it throughout the rest of the quarter.
• User Manual Coordinator. This person is responsible for the user manual part of the documentation. More detail will be given in lab07, and the person in charge will be responsible for updating it throughout the rest of the quarter.
• Final presentation leader (week 9/10). This person will be in charge coordinating the final class presentation video on 12/06. The presentation itself will likely have multiple presenters, but the leader ensures everyone is prepared and everything goes smoothly with demos and setup.

Second CATME.org Peer Eval

All Team members: Fill out peer eval survey (on email from CATME.org) by Wednesday 11/10/21, 10:00pm PDT (midnight in central time)

Start Design Document

Start a Design Document (as a Google Doc or another living document format of your choice) and link to it in a new ./docs/DESIGN.md file in your GitHub. It should contain, for starters, a high-level system architecture overview diagram for your project, with associated explanations of all parts in some text paragraphs accompanying it.

For examples that might stir your creativity, you can check out, e.g., the Requirement Documents in UCSB Capstone projects

You can use any diagramming tool of your choice. Please post in Slack if you like a tool beyond the ones in the list below, but here are some options:

• Google Slides
• LibreOffice (Impress, Draw)
• Microsoft Powerpoint or Visio (if you have access to MS Office)

Or some web-based solutions:

• diagrams.net
• Gliffy
• graphviz

Multi-Platform:

• drawio - see also diagrams.net above

Or on Mac/IOS:

• Flowchart Designer 3

Part II: Deployment Manual

There is a second part to this lab, which has a two-week performance period.