Sprint 2 Expectations

This sprint is about arriving at a well implemented, tested, and thoughtful production-quality feature.

Expectation 1: Project Management & Standards

These remain the same as in the previous sprint.

Issues are kept up-to-date on project boards and closed out when completed. Changes are merged into stage exclusively via pull requests with meaningful code reviews. Commits merged into stage are descriptive following best practices of commit messages.

Angular Material components are used anywhere there are inputs, tables, tabs, etc. If there is an Angular Material component that achieves what your user interfaces need, you should use it in the frontend rather than standard, or bespoke, native HTML controls.

Backend service classes should be tested using Pytest with mock data. Backend service classes and methods should be documented using docstrings following the Google Python Style Guide.

Careful attention to permissions and access control should be paid to adhere to the principle of least privilege. Users should only be able to perform the necessary actions on the permitted resources for their legitimate purpose.

Stories merged in to stage should be of usable, production quality.

Expectation 2: Polish for End-user Stories

The interactions designed for your primary persona should be smooth and polished. This includes user-friendly interactions and form design, friendly error messages for missing fields or issues with data in a form, and thoughtful user experience considerations such as clear user instructions and being sure everything visible works. If there are features you added user interface elements for that are not yet implemented, you should remove them by the end of this sprint. Everything visible should be functional.

Additionally, polish should be added to the implementation wherever possible. You are encouraged to develop a Quality Assurance standards checklist and move through each feature from end-to-end, including docs and tests, and be sure to refactor and/or improve your implementation wherever possible.

Expectation 3: Administrator CRUDS on Primary Entity

Your feature’s primary enetity should have a full set of CRUDS (Create, Read, Update, Delete, and List or Search) functionality for administrators. You are welcomed and encouraged to add a tab to the Admin area when logged in as an administrator. However, if your feature’s design makes more sense to have the CRUDS functionality directly within your feature itself, that is ok.

Search functionality is not required, but if it makes sense in the context of your feature, go for it!

Expectation 4: Improve the Information Design of your Documentation

Take another pass at your information design decisions for documentation in docs/ and be sure it is written for a developer to read. You should avoid language such as, “we would direct new developers to X and give them…”. Your documentation is written directly addressing a developer, not the course staff. If it helps, imagine you are writing for a future COMP423 student working to understand and extend your feature.

Choose plain language where possible.

Improve the formatting of your document to be sure it is easy to read and understand. Make appropriate use of paragraph text, versus merely bulleted lists, where needed. Choose heading text that is appropriate for your feature and the audience, not merely copying text from Sprint 1 expectations. If information would better be represented with a table, use a table instead of a list. This list is not exhaustive. Use your best judgement to make your documentation a great artifact you can be proud of.

Finally, include at least one screenshot of the feature from the end user persona’s perspective in the top level introduction to your feature. Additionally, when describing the key functionality of your feature from either the end user or the administrator’s perspective, include screenshots here, as well. To add an image to your project, place it in the docs/images directory.

Include an authors section toward the top of the document listing the names of everyone in the group with links to their GitHub profiles.

Technical Lead Expectations

Each team with four or more members identified a technical lead this sprint. The duties and restrictions of this role are distinct from earlier sprints. Your primary challenge as a technical lead is to help your team make progress without you writing code.

In this Sprint, you are chiefly responsible for:

1. Code Review - You should perform the code reviews on PRs, carefully and intentionally reviewing submissions and using the review process to improve the quality of PRs where reasonable. Throughout the code review process, you should follow best practices and aim for very quick turnaround times, with the goal of practicing kindness, patience, and care for your team’s morale. Celebrate the good work in PRs!

2. Project Management - You can help develop a Quality Assurance checklist and perform some of the review tasks yourself. Where there are places you can identify opportunities for improvement, you should create issues that are actionable and of an appropriate scope to complete in this sprint. You can propose plans of action and make specific suggestions within an Issue, linking directly to lines of code within the repository on GitHub, but should not be writing or pushing code to the repository.

3. Feature Documentation - You are chiefly responsible for improving the quality of the markdown file for your feature in the docs/ and responsible for Expectation #4. Your engineers are responsible for the documentation of the code base itself this sprint, as well as the tests.

4. Observer/Navigator Pair Programmer and Technical Support Lead - You are permitted to pair program from the observer/navigator role with team members and are encouraged to, if schedules align. You are also encouraged to serve as the technical support lead and help your team members overcome technical hurdles, debugging issues, and so on.

In this Sprint, starting from 4/20, you are not permitted to:

1. Author commits with changes anywhere outside the docs/ directory.

2. Merging PRs after CRs are completed. Your engineers should be responsible for the merging and deploying process.

3. Handling staging issues on CloudApps. You can help as a navigator, but at least one other person on your team should be capable of handling cloud infrastructure concerns. Ideally every member of your team is capable of deploying a merged PR.

As technical lead, this is an opportunity to practice teaching, communicating, and having impact without directly carrying out the work as an individual contributor. These are incredibly valuable skills to practice.

In this Sprint, your team has a reasonable expectation for you to continue to be engaged, present, and contributing to the project, albeit from a promoted role with different responsibilities. You should ask yourself, “how can I serve my team and help us close this project out without writing code?” Additionally, how can you champion their work and help them feel supported and empowered to succeed?

Engineer Expectations

Your expectations remain similar to previous sprints. You should be seeking stories and issues to take on, writing sound code with good documentation and testing where appropriate. You should be collaborating with your team productively and respectfully. When you are blocked, you should collaborate with your technical lead to find a way to become unblocked or something else to take on. When you are looking for ideas on how to overcome challenges, you can ask your technical lead for ideas. If schedules permit, you can pair program with your technical lead, but at this point in the semester you are expected to be able to make progress individually.

In this sprint, you do not need to serve as a code reviewer and can expect timely, helpful, and kind code reviews from your technical lead. You should be able to merge and deploy your own PRs once they are approved for merging.