Skip to main content

Project: Sprint 1 - Feasibility

Sprint Goal: Feasibility (+ effective teamwork)

For the first sprint of the group project, you will establish your team's ground rules, plan your first sprint, and then complete the first increment: propose an app that utilizes a local LLM to assist a user with a task and then demonstrate that your app's core idea is feasible.

info

You will need a laptop that supports WebGPU to complete this assignment.

Additionally, you will need at least 10 gigabytes of free disk space to complete this assignment.

warning

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

Learning Objectives​

  • Author a team contract to document your team's ground rules.
  • Work effectively with others by rooting out both assumptions and pretending in teamwork.
  • Author a project backlog and plan a sprint with GitHub Projects.
  • Author a project proposal for a prototype app that uses a local LLM to assist a user with a task.
  • Evaluate the feasibility of an app idea by prototyping its greatest source of uncertainty first.

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​

  1. Create your team's repository.

    Visit https://landrace.infosci.cornell.edu/courses/info4340-2026fa/repos/project in your browser.

  2. Open your repository in GitHub.

    After creating your repository, visit https://landrace.infosci.cornell.edu/courses/info4340-2026fa/repos/project in your browser and follow the link to open the repository on github.com.

  3. 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!

Project Overview​

Welcome to our start-up's product team! Now that you've completed our onboarding (Homeworks 1-5), you're ready to come up with a new idea for an app.

In this start-up, we value privacy and environmental consciousness. We believe that ChatGPT is overkill for many everyday tasks: it's expensive, it sends the user's data to someone else, and it uses a lot of energy.

In this start-up, you will create a prototype app that solves a problem for our users with AI (LLM). But instead of sending our user's data off into the cloud, you'll keep it on the user's device using WebLLM.

INFO 5440: Your prototype will also be supported by a custom REST API (Node.js + Express).

In your first sprint, you'll need to come up with an idea for an app and then evaluate that idea's feasibility.

Part I: Team Contract​

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. In this part you will establish your team's ground rules and document them in a team contract.

Requirements & Credit​

Credit: Part of the sprint increment grade (~10 points)

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

Team Contract:

  • Author a team contract together.

  • At a minimum, your team contract must include the following:

    • The roles your team will create.

      Who will take notes? Who is responsible for submitting the assignment? Who is responsible for checking the assignment's requirements? Will you rotate through the roles?

      Note

      You may not have programmer and designer roles. Every student is required to contribute equally to programming and design.

    • Your team's policy for attending team meetings and the consequences for not attending.

      tip

      Significant class time is provided for team meetings. (Attending team meetings is part of your effective teamwork grade.)

    • The procedure your team will utilize to resolve conflict.

    • The procedure your team will utilize to verify and submit work.

      Caution

      Effective teamwork is every team member's responsibility. Do not have a single point of failure for submitting the assignment. Failure to submit by the deadline will result in 0 credit for every member of the team. Even if it's the "fault" of one team member.

      Your submission procedure should include redundancy and team verification to ensure that the assignment is submitted correctly and on time.

    • Your team's policy for handling missing work of a slacking team member.

      Do not cover for a team member who is slacking; do not do their work for them! If a team member is not contributing, have them work on non-essential/non-critical path work.

      Never put a team member's name on a submission if they did not contribute to the submission. This is a violation of the code of academic integrity.

    • Your team's procedure for recording the contributions of each team member for each milestone.

    • Your team's procedure for revising the contract.

    • Your team's AI use policy.

      i.e. What is it acceptable to use AI for? What is not acceptable to use AI for?

  • The team contract must be signed by each team member.

    Each team member must sign their own name to receive credit for this milestone. No signature = no credit.

    If a team member does not sign their own name, do not sign it for them. (This is an academic integrity violation.)

Instructions​

  1. As a team, discuss your assumptions about teamwork and your expectations for the project.

    Discuss your goals for the project. What are your goals for the project? Do you want an A+? Do you want something for your portfolio? Do you want to learn something new? Do you want to put in just enough effort to pass the class with a C and nothing more?

    Discuss how you and your team will communicate. What are your assumptions about communications? Do you prefer to use email, Apple messages, or Telegram? Do you expect a response within 30 minutes? 24 hours? 48 hours? Do you expect a 5-minute response time an hour before a deadline?

    Discuss meeting attendance. Do you expect everyone to attend team meetings? Is everyone required to attend class for team meetings? If you can't make it to a meeting, what's the procedure for letting your team know? Do you just not show? Do you send an email 10 minutes after the meeting has started letting your team know that you're really busy with recruitment/interviews, and that you won't make it?

    Discuss with your team how you will use AI. What is it acceptable to use AI for? What is not acceptable to use AI for? Should you seek permission from the team before using AI for some types of tasks? (e.g. design, writing, etc.)

    Discuss how your team will check your work and submit it. It is every team member's responsibility to ensure that the work is submitted correctly and on time. What is your team's procedure for checking the work and submitting it? How will you ensure that the submission is correct and complete? How will you ensure that the submission is made on time?

  2. Discuss and document your ground rules in a team contract.

    Create a markdown document in your project repository (team-contract.md at the root of the repository).

    Feel free to use the following template as a starting point for your contract; you may ignore the provided template and create your own contract from scratch if you wish.

    1. To what goals do we all commit?

      TODO

    2. What are our “ground rules”? (Don't make an exhaustive list—stick with just a few, like "listen when others are talking; don't distract yourself with your phone or laptop", "never interrupt another person when they are talking", and "assume the best in people rather than malicious intent".)

      TODO

    3. By what means and how frequently will we communicate?

      TODO

    4. What are our expectations for attending team meetings? What are the consequences for not attending?

      TODO

    5. When will we complete our individual work? (10 minutes before the deadline; the day before the deadline, etc.) When will we complete our group work? How will we ensure that we are all contributing equally?

      TODO

    6. What is our procedure for checking our work and submitting it to the instructor?

      TODO

    7. What is our policy for handling the work of a slacking team member? What do we do if a team member is not contributing equally?

      TODO

    8. How will we hold ourselves and one another accountable? What (exactly) will we say to a team member who appears not to be contributing equally? To a team member who fails to deliver what was promised?

      TODO

    9. What do we do when we disagree? What approach to conflict do we all agree to uphold?

      TODO

    10. What roles will we create? Include a description of exactly what each role is responsible for. (Roles may rotate. You may not have "designer" or "coder roles". Everyone must equally design and code.)

      TODO

    11. What is our policy for using AI to complete our work? What is acceptable to use AI for? What is not acceptable to use AI for?

      TODO

    12. What are our procedures for re-visiting this contract?

      TODO

    Add your full name and the date you signed this contract.

    • TODO
    • TODO
    • TODO
    • ...

  3. Sign the team contract.

    Each team member must sign their own name to receive credit for this milestone.

    Sign the contract in your own codespace, with a commit that is attached to your GitHub account. No commit for the signature = no credit.

    If a team member does not sign their own name, do not sign it for them. (This is an academic integrity violation.)

Submission​

Submit nothing at this time. You will submit your team contract in the last part of this assignment.

Part II: Project Backlog & Sprint 1 Plan​

Create your project backlog and plan your first sprint 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:

  • Each team member has created issues in the backlog.
  • 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 1 Plan:

  • The sprint 1 plan includes (at least) issues for the team contract, the project proposal, and the feasibility demonstration.
  • 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 1 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. In GitHub Projects, set the default repository to your project's repository.

  3. In GitHub Projects, set the sprint (iteration) dates to match the course schedule.

  4. As a team, create issues for your backlog and then prioritize them.

    Create issues for all the tasks you need for this sprint. You may create issues for future sprints, but you will not be graded on them.

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

  6. Take one screenshot of your sprint 1 plan from GitHub Projects' Sprint Planning view.

    tip

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

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

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

  8. 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 1 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 III: Sprint 1 Increment​

The increment is the finished, working output your team delivers at the end of a sprint (iteration). In this part, you will complete the issues you committed to for sprint 1: your project proposal and your feasibility demonstration. You must complete all the issues you committed to by the end of the sprint.

For your project, your team will design and implement a prototype app for our start-up's product suite that uses a local LLM to support a user with a complex task.

The app should be substantial: bigger/more complex than the homework prototypes. A rule of thumb: take Homeworks 3, 4, and 5 and combine them into a single app (and then add a bit more complexity). That's about the size and complexity for this project.

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 1 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.

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.)

Proposal Requirements:

  • Document your project idea in the README.md file. The proposal should include:
    • A description of your app idea and the problem it solves.
    • The intended users of the proposed app and their primary task.
    • How the proposed app will use a local LLM to assist the user with their task.
    • Why a local LLM is enough for this task (i.e. why ChatGPT is overkill).
    • The ideas your team considered and evaluated, and why you selected this one (see the feasibility demonstration).
    • INFO 5440: A description of the REST API that will support the proposed app.
    • No credit provided for a link to another document; everything must be in the README.md file.

Feasibility Demonstration Requirements:

  • A demonstration that your app's core idea is possible (greatest source of uncertainty/risk) is located in your repository.
  • Add a Feasibility section to your README.md file that documents your feasibility demonstration.
    • Explain how you evaluated the feasibility of your idea and where we can find the demonstration in your repository.
    • The demonstration can be anything that helped you evaluate your idea: a spreadsheet, a log of prompts and responses, a proof-of-concept script, etc.

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 1 plan.

    note

    You need not fulfill all the project requirements for this sprint. You have four sprints to do that. But you do need to make progress towards them in this sprint.

  2. Close each issue when it's complete.

  3. 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 sprint1 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
Last updated on