lab03 : First Team Retrospective

num	ready?	description	assigned	due
lab03	true	First Team Retrospective	Thu 01/30 04:00PM	Thu 02/06 07:00PM

label

What you need to finish TONIGHT

Recording your team’s retro artifact

It might be convenient to store the team’s retrospective artifacts in one of our existing places (e.g. under the team directory of the repo, or on the team repo’s wiki).

However, there is a sense in which a team’s retrospective artifacts should really be private to the team itself.

It will also help the instructional staff to have a consistent naming convention so that we can locate your retro artifacts for course grading purposes.

Create private team-name_RETROS repo

Accordingly, the team should please create a *private repo with the name as indicated below.

• The retro leader should take responsibility for making sure this happens, but…
• It is totally appropriate to delegate the actual creation to another member of the team
• It is helpful if this happens before the class meeting where the retro is scheduled.

First thing: go to https://github.com/ucsb-cs48-w20 and create a new *private repo with your teams name followed by the suffix _RETROS

For team	create repo	with link
4pm-stock-trading	4pm-stock-trading_RETROS	4pm-stock-trading_RETROS
5pm-pet-life	5pm-pet-life_RETROS	5pm-pet-life_RETROS

etc…

Create it as follows:

• private
• with a README.md
• no .gitignore and no LICENSE needed

Then, add each of the team members to that repo as collaborators, by their github id, as admin level collaborators.

It is not necessary to add your mentor, TA or instructor—we have access automatically since the repo is created under the github ucsb-cs48-w20 organization.

Recording the artifact

Make a file called retro1.md in the repo.

Required

In the file:

• Record who led the retro
• Record the list of which team members participated in the retro
• Record the EXPERIMENT that your team will undertake as a result of this retro
  • Something your team will do differently
  • What result you hope to get
  • How you will measure whether you got that result

Optional

• Record anything else you think the team might want to remember from this retro

Over the next week: MVP Planning

To help your team (as well as your instructional staff) know what you are defining as part of your MVP—which you are delivering two weeks from today , we are asking you to do things process/tool wise:

• Create a new column on your Kanban board.
  • Call it MVP, and put everything (in terms of user stories and issues) from the TODO column that is part of MVP into that column.
  • Leave everything that is NOT part of MVP in the TODO column.

In addition, issues on Github can have labels. Github creates some predefined labels, but can edit these and add new ones.

• Add a new label called MVP.
  • Add that label to all of the issues that are in the MVP column, as well as any issues that are already in-progress or done that are part of your MVP.

Finally, while regular cards cannot be given “labels” in the same way that issues are, you can just use the letters (MVP) in parens as a kind of label on the user stories that are part of your MVP.

In this way, anyone can look at your Kanban board, and see:

• What is, and what is not part of your MVP
• Which user stories and issues are still not started, in progress, or done, with respect to your MVP.

Deliverables and Grading for lab03

By the end of due date of this assignment (i.e. Thu, Feb 06 at 7:00PM), you should be halfway done with delivering a significant number of issues towards your MVP.

Here’s what we’ll be looking for and grading: