Project: Sprint 2 - Core Functionality

Sprint Goal: Core functionality (+ effective teamwork)

For the second sprint, you will plan the sprint with your team and then deliver the second increment. Build on your feasibility demonstration: get your app's core functionality working.

warning

The provided slip day and resubmission accommodations may not be used on group assignments.

Learning Objectives

• Plan a sprint and deliver a sprint.
• Effectively work and communicate as a team to deliver a sprint.
• Evaluate the feasibility of using a tiny LLM to assist a user with a complex task.
• Utilize prompt engineering techniques, like one-shot, few-shot, chain-of-thought, and RAG, to provide context to a tiny LLM in support of a user's complex task.
• Employ coding agents to prototype a working high-fidelity app.

Help & Support Resources

We want you to get the help and support you need. Use the course's support resources for help with this assignment.

Git Repository & Codespace

Continue working in your team's project repository: https://landrace.infosci.cornell.edu/courses/info4340-2026fa/repos/project

Open your repository as a codespace.

Submission Requirements

Professionalism

Professionalism means meeting the client's requirements. Not doing less and not doing more.

Your assignment should meet the following requirements for credit:

• Submit your own original work (design and code) for this assignment.

  No credit is provided for submitting design and/or code that is taken from the course-provided examples.

• Your code should be original. However, the structure of the code will mirror the class examples.

  The structure of your code will align with the class examples. This is to be expected.

• You are required to use the methods and techniques covered in class.

• Your assignment's prototype should be visible in the browser and functional upon launching the development web server using Run Without Debugging.

  If your assignment does not launch using this method or is not visible in the browser after launching the development server, we are unable to provide any credit.

  INFO 5440: Your REST API server must be launched successfully using the provided commands, and your app must successfully communicate with your REST API server.

• All files should be in the location specified in this document for credit.

  Professionalism is important. Incorrectly placed files will not be graded; no partial credit is provided either.

• Follow the submission instructions below.

  Submit all materials to your GitHub repository's main branch for this assignment. When you're finished, stage, commit, and push your submission to GitHub. Then fill out the submission form to complete your submission.

  Failure to complete the submission form will result in 0 credit; no submission form = no submission. No leniency. No exceptions.

Effective Teamwork

Working effectively together is every team member's responsibility. If there's a conflict, address it. Don't pretend that the conflict will simply go away.

Resolving Conflict

Conflict is a healthy part of any team relationship. If your team doesn't have conflict, then your team members are likely not communicating their issues with the other team members. This is bad. Use a team contract to keep your team dynamic healthy.

When you have conflict, you should follow this procedure:

1. Refer to the team contract and follow it.

2. If you resolve the conflict without issue, great! Otherwise, update the team contract to improve your ability to work together moving forward. This is required.

3. With the updated team contract, try to resolve the conflict.

4. If that fails, contact the instructor. I'll ask to meet with all the group members and figure out how we can work together to move forward. I will not help your team unless I see that the team contract has been updated to try and resolve the conflict internally first.

5. Do not avoid confrontation if you have conflict. If there's a conflict, the best way to handle it is to bring it into the open and address it.

The Slacking Team Member

Do not cover for a team member who is slacking. This only rewards their bad behavior. Never put a team member's name down for a submission if they did not contribute. This is a violation of the code of academic integrity.

Tip

If you have a team member who is not contributing, have them work on non-essential work for the project. Maybe that's making them responsible for designing/coding an optional top-level view. If this view doesn't get made, since it was non-essential, that's okay. If it does, great!

Part I: Updated Backlog & Sprint 2 Plan

Update your backlog and re-prioritize it based on what you learned from sprint 1. Then, plan sprint 2 in GitHub Projects.

A Sprint Plan is a Commitment

Your team commits to completing every task in your sprint plan by the end of the sprint. No exceptions.

• You cannot change your sprint plan after it is submitted. (You may add new issues to the backlog, but not to or from the current sprint.)
• If you don't complete the work you planned, then you didn't complete the sprint, and you will not receive full credit.
• Your plan should be ambitious, but realistic.

Requirements & Credit

Credit: 10 points

This part is graded for correctness. Meet the following requirements for full credit:

Backlog:

• The backlog has been updated and re-prioritized since the last sprint.
• The backlog is thorough: it includes all issues that you need to do, including the cool features you want to add and the basic features your app needs to work.
• The backlog is prioritized by risk: the riskiest assumptions and greatest sources of uncertainty are at the top.

Sprint 2 Plan:

• Each issue is specific: it clearly describes what will be done and how the team will know it's done (acceptance criteria).
• Each issue is assigned to the team member(s) responsible for it. Work is divided equitably.
• Submit one screenshot that clearly shows all the issues assigned to Sprint 2 in the Sprint Planning view to Canvas.

Commitment:

• Once the sprint plan is submitted, you may not change the issues for the sprint; you must deliver all the issues planned for the sprint.
  • Exception: You may add Sub-Issues to an existing issue to divide the work across team members. However, you may not add sub-issues that change the scope of the issue.
  • Exception: The team contract can be updated at any time.

Instructions

1. Read the requirements for the sprint in the part below.

2. Update your backlog in GitHub Projects. Re-prioritize it based on what you learned in the previous sprint.

3. In the Backlog view, assign issues to the Sprint 2 iteration. Assign each issue to a team member.

   Suggestion

   Sketches, like those we create in class, often take much less time than creating Figma mock-ups. Given the short duration of the projects and its sprints, using Figma to produce mock-ups is a poor use of your team's limited time and resources. Especially considering no credit is provided for mock-ups.

4. Take one screenshot of your sprint 2 plan from GitHub Projects' Sprint Planning view.

   tip

   Firefox has a screenshot tool that lets you capture the entire page.

5. Submit your project plan screenshot before Tuesday's class to Canvas.

   You are now required to deliver all issues in this sprint.

6. After planning the sprint, you may optionally create sub-issues for each issue to divide the work across team members.

   Warning

   You may not add sub-issues that change the scope of the issue.

   You may only use sub-issues to divide the work across team members.

Submission

Upload a PNG or PDF screenshot of your sprint plan before class on Tuesday (sprint 2 check-in).

The sprint plan must reside inside the screenshot. No credit for PDF files with links to other documents. (We will not follow any link provided in a PDF file when grading.)

warning

It is every team member's responsibility to verify that the PDF is complete, ready to be graded, and correctly submitted before the deadline. One person forgetting to submit will result in a 0 for the entire team.

Part II: Sprint 2 Increment

In this part, you will complete the issues you committed to for sprint 2. You must complete all the issues you committed to by the end of the sprint.

Requirements & Credit

Credit: ~50 points

This part is graded for correctness. Meet the following requirements for full credit:

Sprint:

• All the issues committed to in the sprint 2 plan are complete and meet their acceptance criteria.
  • Every commit is associated with an issue from the sprint plan using the #issue-number syntax in the commit message.
  • Your team may not change your sprint plan.
• The work completed (design, testing, planning, coding, etc.) is done well and to the standards set by the course.
• For full credit, the work completed should be ambitious.
• Provide a brief description in the README how the graders can test the work completed in the sprint.
  • Provide sample data for the graders in your repository.
  • The data should be realistic and representative of the data your app will process.

Project Requirements:

• Design and implement an app prototype that uses a local text-based LLM to support a user with a task.

  • Support need not mean generate. Instead, think assist. How can the LLM assist a user with a task? (For example, autocomplete is a form of assistance.)
  • You may only use text input and output when working with the local LLM; no computer vision or image generation is possible.
  • The local LLM model is small (1-3B parameters) and runs entirely in the browser using WebGPU.
  • The prototype should provide context to the model employing at least one of the methods covered in class (e.g. one-shot, few-shot, chain-of-thought, RAG, etc.).
  • The response time from the local LLM is reasonable.

• The app prototype supports a user with a complex task.

  • Single "one-shot" tasks, like computing the contrast ratio between two colors, are not complex enough for this project.
  • Productivity apps, apps that inspire creativity, and problems with unstructured data are good domains. For example, a slide maker supports a user with a complex task (making a presentation) by supporting many small tasks (making a slide). (See the slides side panel or the notes side panel.)

• The app prototype uses what you learned during your "onboarding period" (Homeworks 1-5).

  • Implement your app prototype using JavaScript, Vue.js, Tailwind CSS, and DaisyUI (optional).
  • You may use features that were not directly covered in class. That's fine. Just make sure you understand them so you can explain them during your "performance review" (i.e. final oral exam).

• The app prototype looks and feels like a real app (not a website).

  • The app prototype is a laptop or a mobile app (pick one).
  • Use app design patterns, not website design patterns.
  • The app must fill the entire window (left to right, top to bottom) and adapt (relative dimensions; not fixed) when the window is resized. (No content centered with whitespace around it like a website.)
  • However, the app need not be fully responsive (i.e. it need not respond to different screen sizes with different layouts, like for a mobile phone or a tablet).
  • Avoid "boxes inside boxes inside boxes" (e.g. cards nested in cards nested in panels). AI design tools love to do this. It's cluttered and wastes space.

• The app prototype provides a usable user experience.

  • The app prototype is reasonably speedy. Slowness/sluggishness harms the user's experience.
  • The app prototype manages the user's experience when the LLM is processing a request; the user is never left sitting watching a progress bar for long.
  • The app prototype is well-designed, polished and professional.
  • The app prototype communicates to the user what's going on. (The user should never be left wondering if anything is happening.)

• The app prototype remembers the user's data via the LocalStorage browser API.

  • The user should not need to constantly re-enter their data every time they open the app.
  • For testing purposes, you may optionally include a clear data feature.

• The app prototype runs entirely in the browser, is self-contained (no calls to external service APIs or services, like Google Maps, YouTube, or ChatGPT, etc.).

  • Libraries installed via CDN are not permitted.

• The final app prototype is installable as a PWA.

INFO 5440 only:

• Your proposed app must be supported by a REST API that your team will prototype.

  For example, a REST API that provides data to the app or processes user input (e.g. re-encodes a video). The REST API may not use an LLM.

• Your REST API should be implemented in Node.js and Express.

  • Your REST API server should be located in the server directory at the root of your repository.

  • The REST API may use other services, like MongoDB or PostgreSQL, but they must be hosted locally in the container. No external services. (Exceptions are possible, but seek instructor permission first.)

  • The REST API must start with the following commands, or you will not receive credit for the REST API:

    cd server
    npm install
    npm run dev

Prohibited:

• The following classes of apps are not permitted (though some exceptions may be possible with approval from the instructor):

  • No chatbots
  • No "trackers"
  • No "generators"
  • No "planners"
  • No "calculators"
  • No "student" centric apps (e.g. reserving office hours, automatic regrade requests, etc.)
  • No shopping apps with shopping carts

• The following are not permitted in the app prototype:

  • No accounts / logins
  • No calls to external service APIs
  • No server-side code (INFO 5440: server-side code only for your team's REST API (Node.js + Express), which may not use an LLM.)

Effective Teamwork:

(~10 points, graded individually)

note

Your teamwork grade for each sprint will be evaluated at the very end of the project.

• You will be evaluated on your ability to work effectively with your team based on the following:
  • Peer feedback collected at the end of the project.
  • Your contributions submitted in the repository (all your work must be committed by your user account.)
  • Your class meeting attendance.

Instructions

1. Complete the issues in your sprint 2 plan.

   note

   You need not fulfill all the project requirements for this sprint. You have until the end of sprint 4 to do that. But you do need to make progress towards them in this sprint.

2. Close each issue when it's complete.

3. Include any instructions to the grader on where to find the work you completed for sprint 2 in the README.md file at the root of the repository.

   Provide sample data for the graders in your repository. The data should be realistic and representative of the data your app will process.

4. Test and verify that your sprint is ready to be graded.

Submission

Thoroughly check your submission and verify that it is ready to be graded. (We're unable to accept redos for forgetting to include parts of the assignment in your submission.)

One team member must complete the submission form for sprint2 to submit the assignment.

warning

It is every team member's responsibility to verify that the work is complete, ready to be graded, and correctly submitted before the deadline.

One person forgetting to submit will result in a 0 for the entire team. No exceptions.

Contributors

Copyright © 2023 - 2026:

• Kyle Harms