M1 Development Iteration

---

Milestone M1 Checklist

☐ Demo video

☐ Demo video report, including who-did-what part

☐ Version of your code from the demo video in a GitHub release (URL submitted to eCourseware dropbox)

☐ Up-to-date versions of your user stories, definitions, model-class design, and reporting artifacts (submitted to eCourseware dropbox)

☐ Task reporting in the form of GitHub issues and pull requests

☐ Customer sign-off

☐ Teammate evaluations

---

There are two main deliverables for Milestone M1: a demo video and a collection of project artifacts.

1. Demo Video and Video Report

Your team will be responsible for creating a demo video of your software. This video is mainly to assist the course instructors in grading your progress on the project. The video must also have an accompanying video report that includes a who-did-what report that lists who built each of the demoed features. The demo video and document must meet the following grading criteria:

• Criterion: Demonstrate the progress that the team has made so far.
  • All the new features. Include all the latest features in the demo. Don’t leave any out. A big point of this exercise is to demonstrate all the wonderful progress that the team has made. Note that this criterion does not mean that you should skip re-demoing old features. It just means you shouldn’t skip the new ones. However, you should not include old work in the who-did-what report.
  • Backend too. Although UI features are a high priority, you may also demonstrate that backend functionality is working, even if it’s not yet connected to the frontend. The key thing is to prove that the code runs and works! Along those lines, you may demo automated tests.
• Criterion: Display the team’s work in the best possible light.
  • Story form. Any demonstration of UI must take place in the context of a cohesive story. That is, the presenter must describe one or more characters (with names, like Alice and/or Bob) and relate a story about the character using the software. The presenter must stick to this story format. The story and accompanying demo must be well thought out, and not leave the audience with the impression that the presenter is making it up as he/she goes along. Use realistic names for things and not made-up placeholders, like “foo” and “slafjsd”.
  • UI first. Since the UI is generally most interesting, you should lead with that.
  • General audience. Don’t forget that not everyone is as familiar with your project as you are. To be on the safe side, explain it as if you are talking to someone who has never seen it before.
  • No special effects or fancy editing. The video should clearly show a user (or users) interacting with your web app. Don’t add special effects or sound effects, which distract or detract from the authenticity of the interaction.
• Criterion: Length and format constraints.
  • Time limit. The video must be no more than 10 minutes long.
  • Fill the time. Your video should be at least 6 minutes; otherwise, you’re probably doing something wrong.
  • Video format. The video must be shared via YouTube.
• Criterion: Make clear who contributed what to the project in the video report.
  • New work only. Although you may demo features from previous iterations in the video, the who-did-what report should only mention features/work that are new to the latest milestone submission.

Note that the creators of the demo video and accompanying video report are eligible for A&B points.

2. Project Artifacts

For Milestone M1, you will submit the following artifacts:

1. a copy of your code (as a release in GitHub), and
2. up-to-date versions of your requirements, design, and reporting artifacts (especially USs, definitions, and model-class diagram).

The artifacts should satisfy the following grading criteria:

• Release in GitHub. To grade your code, I will download your milestone GitHub release.

• Code builds and runs. I should be able to build and run your code using the usual approach from the Boot Camp projects. If any special instructions are required to build/run your software, include them in the README file in your project’s top-level directory.

• Replicable demo. I should be able to replicate your demo video. If seed data is required to do so, you must somehow make that data available to me (possibly giving instructions in the README).

• Artifact quality. All your artifacts must be of high quality. The criteria from the Milestone M0 still apply, with the following addition.

• Code quality. Your code must follow common style guidelines and be well organized and readable. For example, all code must be properly indented, and class/variable/method names must be sensible. You should also do your utmost to avoid bugs and other sloppiness.

• Customer satisfaction. Your customer will provide feedback on how well your team has satisfied the requirements they gave you and how well aligned your team’s prioritization of the work has been with the customer’s priorities.

Note that there is an A&B eligible role (Quality Assurance Czar) with special responsibilities regarding milestone artifact quality.

3. Project Workflow, Task Planning, and Task Reporting

All work contributed to the project must follow the process described in the Project Workflow Instructions document. This process includes full task planning and outcome reporting.

4. Submitting the Milestone

4.1. Customer Sign-Off

Before your milestone submission will be considered complete, your customer have signed off on it, as per the form below. (Note that I will contact the customer directly to collect their sign-off, so you need only to get their verbal approval.)

4.2. GitHub Release

Once all team members tasks have been completed and their pull requests have been merged into the master branch, your team must create a release for the milestone:

• Set the Tag version to m1v1. If changes (e.g., bug fixes) are made to the release after it is created, you can create a new release that includes the changes—just be sure to increment the version (e.g., m1v2).
• Set Release title to Milestone M1, Version 1 (replacing Version 1 with the appropriate version of the release).

4.3. eCourseware Dropbox Submission

As the last step, your team must submit the following to the appropriate eCourseware dropbox. Only one team member needs to perform this step. If you need to correct a release, don’t forget to resubmit the URL as well to reflect the correct version.

• URL of the GitHub release page, as a text comment in the dropbox.
• All requirements, design, and reporting artifacts (including anb.docx, db_design.pptx, definitions.docx, stories.xlsx, and video_m1.docx).

5. Teammate Evaluations

At the end of each iteration, each team member must provide an evaluation of each other team member. Instructions and forms for performing these teammate evaluations will be communicated by email near the end of the iteration.

---

Milestone M1 Customer Sign-Off Form

Customers: Please indicate your approval of the following items—but ONLY if you agree 100% with the statement for the item.

If you have ANY disagreement, do not give your approval. Instead, provide the team with feedback, and have them resolve whatever issue is preventing your approval.

☐ New! I have reviewed a demo of the software, and I have provided the team any feedback I had.

☐ I have reviewed the user stories, and they are up to date and consistent with my wishes.

☐ I have reviewed any new user-interface designs, and I approve of them.

---

Grading Rubric

Below are each of the grading items for this Milestone, along with their point values and weights. If an item is not submitted at all, 0 points will be awarded for that item. The top-level bullets specify grading criteria. The sub-bullets indicate standard deductions for errors in a submitted item. The deduction list below may not be complete because there may be mistakes that we did not expect. The deduction for an unexpected mistake will be assessed at the time it’s discovered and will reflect how severe the instructor thinks the mistake is. If the deductions for a grading item total more than the total points for that item, 0 points will be awarded for the item.

Progress on Product

20 points with weight of 30%

• Made inadequate progress given the number of team members and time in the iteration
  • -2 to -20 depending on severity

Demo Video

20 points with weight of 40%

• Fails to provide a gentle introduction that addresses a general audience
  • -2 deduction
• Fails to tell a user-task oriented cohesive story
  • -3 deduction
• Fails to use realistic data
  • -1 to -3 depending on severity
• Fails to demo key features that arguably should have been demoed
  • -1 for each missing feature up to -5
• Fails to differentiate old and new features
  • -2 deduction
• Bad demo length
  • -1 per minute too short up to -4
  • -1 per minute too long up to -4
• Bugs apparent
  • -1 per bug up to -3
• Problems with the video report document
  • -5 missing document
  • -3 fails to follow Markdown template

Process

Overall weight of 30%

Task Reporting

20 points with weight of 5%

• Failed to document outcomes of tasks
  • -10 deduction
• Failed to follow instructions
  • -2 per mistake up to -6

Release

20 points with weight of 5%

• Failed to upload correct release URL to eCourseware on time
  • -8 deduction

User Stories and Definitions

20 points with weight of 10%

• See Milestone M0 rubric
• Not up to date
  • -6 for not keeping statuses up to date
  • -2 per clearly missing user story (e.g., for features already implemented)

Model Class Diagram

20 points with weight of 10%

• See Milestone M0 rubric
• Not up to date
  • -10 Not updated to be consistent with model implementation