Meetings - Team Expectations

You will meet (at least) twice a week with your project manager and team. One meeting will be in person, during your scheduled recitation time. The second meeting time per week will be scheduled by the team at the start of the term and last for the entire semester.

Before Weekly Meetings

You are expected to complete all of your assigned tasks and stories by the deadline set by your PM. Completing your tasks means:

  • The tasks and stories were updated with proper labels & assignees. If the "Needs Revision" tag was applied, the card must be revised and the tag removed once the revision(s) completed;
  • Tasks & stories were moved into the "In Progress" list when you start working on them;
  • Tests were reviewed and additional tests, if needed, are added to the task/story;
  • Branch(es) were created & all work is committed to your repo;
  • The cards are moved to the "Testing" list;
  • AFTER running and passing all of the tests, (if appropriate) a pull request merges the branch to dev is merged to "dev", and the card is moved to the "Completed" list.

If you cannot complete all of your assigned work, you must notify your entire team (including the PM) by the deadline.

Between PM Meetings

Immediately after your PM meeting, you need to update any cards the PM assigned to you:

  • Make certain you are listed in the Member area of any tasks;
  • Verify the cards include the correct tags and have accurate tests;

Soon after your PM meeting, go back through your scrum board and be certain to fix the titles and tests on any of your assigned cards to which your PM added a "Needs Revision" tag. Once you make the required changes, remove the tag.

When starting work on a task, you will to take steps to make certain you do not need to go back and redo your work:

  • Move the task you will be developing from the "Planned" to "In Progress" list;
  • Double-check that the task is blocking a user story;
  • Re-read the task tests. Clarify any tests that are not clear and add any tests that might be missing;
  • If the task will require commits to your repo and does not yet have a branch, create a branch from "dev" and link the card to it.

If you discover a bug in an already completed card, you need to document your efforts to fix it:

  • The task and/or story should be moved back to the "In Progress" list;
  • Add AT LEAST 1 TEST to the task/story. The test(s) should expose the bug(s) you found;
  • Update the branch(es) to the current code base and commit your bug fixes to the repo;
  • Move the card(s) to the "Testing" list;
  • AFTER running and passing both the old and new tests, use a pull request to merge the branch(es) to "dev" and move the card to the "Completed" list.

When you think work is complete, it is important to communicate this AND build your teammates' confidence in your results:

  • Move the card to the "Testing" list;
  • Run all of the tests EXACTLY how they are written. You can (and should) add any details or steps that are missing;
  • If all the tests pass, move the card to the "Completed" list. If there was a branch associated with this work, use a pull request to merge the branch to "Develop";
  • If one or more tests fail, move the card back to the "In Progress" list and make the changes needed to correct the error(s).

Before Sprint Grading Meetings

You are expected to complete all of your assigned work by the deadline set by your PM. You and your team will also need to prepare the repo, scrum board, and application to properly reflect that the grading meeting is a release of software.

  • Meet with your PM and have them go through your scrum board to mark all completed work as closed;
  • Branches created for completed/closed tasks should be merged back into the "Develop" branch;
  • The code in the "Main" branch should be used to install the application on the TEST and PROD systems;
  • Your PM will use a pull request to merge the "Develop" branch into the "Main" branch;

Each sprint is graded by demoing your product for the PM/client. For each sprint, you should only demo the code in your repo's "Main" branch. The demo MUST be run on a PROD system and not in localhost or using a simulator/emulator.

The PM/client will be responsible for choosing and running acceptance tests which were completed during the just-completed sprint. The PM/client also chooses task tests to run from the tasks that were completed during that sprint. The PM/client can run these tests before, during, or after the demo since the demo time is limited. In addition to the tests, the PM/client can test issues using other inputs to verify that there are no bugs due to overlooked cases.