List view
- Due by December 15, 2025•15/19 issues closed
- Due by December 1, 2025•44/44 issues closed
- Due by November 10, 2025•26/26 issues closed
The goal of this Sprint is to implement a more robust version of the core functionality, perhaps using some real data, and perhaps some minimal quality versions of the next set of features. This sprint emphasizes giving the client some confidence that the basic app is up and working and help give them a sense of what the final version can be. By the end of this Sprint, a version of the app must be deployed in some meaningful way (i.e., on your personal device or on a server others can get access to). ## Team Contract, Version 2 Update your agreement for how your team will operate based on your assessment of the parts of the contract that are still useful, those parts that need to be updated, or what needs to be added after reviewing these resources: - Team Canvas - Social Contract - Teamwork is an Individual Skill Checklists (especially the quiz at the end) Essentially, now that you know each other better and have shared experiences, this gives your team a chance to create a more realistic set of goals that better reflects how your team wants to communicate and solve problems collectively, especially ways to handle negative team situations. In your project repository's Wiki, update your Team Contract to reflect your team's collective goals for working together. By adding this document to your project's repository, each team member implicitly agrees to abide by it. ## Accessibility Plan This documents describes your apps primary accessibility concerns and how your team will work to prioritize this important issue during your Sprints. Review the W3C guidelines and then test your current implementation to find accessibility issues in order to give you a sense of what you need to pay more attention to. Then, for each major app feature, list the following: Tests: all accessibility concerns you can think of to test Improvements: concrete tasks that you can take to improve accessibility Then, add the tasks you created to your Backlog, either as separate tasks to be discussed and prioritized at each Sprint Planning or as part of your Definition of Done for existing tasks. ## Design Justification This document describes why the team has designed the software the way you have such that anyone familiar with the project and with a technical background can read to understand the project's organization, what choices the team made, what the design assumes will not be changed, and what the design attempts to make flexible so that it can be easily changed or extended. This document serves as a roadmap to help those that might maintain the software or make decisions about how the app will be extended in the future. This reading argues for the importance of this document, this reading describes a process for making decisions, and these are real-world examples. In your repository Wiki, describe the high-level architecture and goals of your design (rather than low-level code specific implementation decisions). Like User Stories, you can also use stories to justify or explain design choices because they help make even abstract things like software design more comprehensible to non-technical members of the team. Additionally, justify significant decisions your team has made in relation to the project's design goals (whether it was code you wrote or a library or framework you used instead of writing it yourself) using the following template: - the issue requiring a decision - the choice that was ultimately made - the justification for the choice - the other alternatives considered - the trade-offs evaluated - any assumptions that may have had an impact on the decision - any dependencies on the decision that impacted other issues ## Demo Presentation Since this presentation serves to wrap up a Sprint, in addition to showing your team's progress on the app, it should show that your team has reflected on its progress and planned for the next Sprint. Your presentation should be limited to 12 minutes and include a demo as well as some key ideas from this Sprint: - Demo. a working version of the app, highlighting complete client facing features that have been added during this Sprint and noting who worked on which features - Value. justify why this set of features was chosen to be implemented this Sprint - Accessibility Plan: what were the most surprising things you learned from testing your app for accessibility issues and how do you plan to prioritize accessibility going forward - Design Justification. justify two design choices your team made to make the app more easily maintainable or changeable by the client (including alternatives you considered is encouraged) - Timeline. show your Burndown chart and provide a brief timeline of significant events that occurred this Sprint and how communication was handled for each event (i.e., how each person was involved or learned about it later) - Team Reflection. explain what state your team is in, one thing that worked, one thing that did not, and one thing you added or changed about your Team Contract - Planning. the User Stories your team has prioritized for the next Sprint, who will work on each feature, and any blockers that may complicate the plan ## Expectations: - Freeze your main code branch, i.e., stop adding new features, at least 12 hours before the demo to allow time to practice your presentation and prevent last minute emergences Fixing small bugs (and tracking those bugs) you find as you practice using your app for the demo can still be helpful but, in some cases, it may be better to find a workaround that can be practiced and used during the demo instead (e.g., using specific inputs, order in which features are presented, etc.) - Practice delivering the presentation beforehand since it is not a lot of time to fit in everything asked of you - Focus on the value your features represents to the users, not on the technical details of how it will get done - Each person on the team should talk at some point during the presentation All materials related to your presentation must be pushed to your Gitlab repository or Wiki either as code, images, or written text (using Markdown). PowerPoint slides are discouraged because they are completely separate from the project and unlikely to be maintained even if they are added to the repository, but here are some tools to convert Markdown to a slide style format.
Due by October 27, 2025•5/5 issues closedModularizing the code and refactoring it to better suit OOP style. Moreover, get ready to make a python package.
Due by October 6, 2025•14/14 issues closed