lab07 : Review and Plan Leadership Roles / Start Design Document / Inter-team Eval

num ready? description assigned due
lab07 true Review and Plan Leadership Roles / Start Design Document / Inter-team Eval Fri 02/21 12:00PM Fri 02/28 11:59PM
Points

The first item is part of the inter-team evaluation taking place in class on Wednesday, February 26: You are being paired with another team from the class and all those team members will deploy and evaluate your current product and subsequently give you feedback. They will read the USER_FEEDBACK_NEEDS.md you are finalizing today, and are tasked to give honest impressions and recommendations.

Graded: (lab07-I) (30 pts) For individually deploying and reviewing your partner team’s app and for submitting the evaluation form report we will point you to. This report should be created during and after Lecture 13 and should contain all items indicated on the lect13 notes.

Graded: (lab07-T) (15 pts) You earn these team points if you have planned future team leadership roles and logged them in your GitHub team/LEADERSHIP.md as per instructions below

Graded: (lab07-T) You earn these team points if you started a design document that you link to in your Github ./docs/DESIGN.md and that contains at least:

  • (15 pts) an overview system architecture diagram and associated explanation.
  • (20 pts) a Section summarizing important team decisions since the start of the project, referring to meetings logged in your GitHub repo
  • (20 pts) the beginnings of a Section talking about your User Experience (UX) considerations. A high-level task/user flow (see below) might be the first thing to document there, and it would also be helpful for determining the structure of your manual (next week’s lab).

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 at least 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

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 #help_diagrams if you like a tool beyond the ones in the list below, but here are some options:

Or some web-based solutions:

Multi-Platform:

Or on Mac/IOS:

The exact structure of the Design Document is left to your team to determine, but to get you started, we recommend at least the following set of sections in some form and order:

User Flow

A high-level overview (diagram and associated explanation) of your product’s Task/User Flow can be used as the starting point for the UX section in your Design Document and also for planning/structuring your user manual.