A semester long project can easily get off track without consistent effort made each week and regular evidence of your team's progress. In this course, we will be using Scrum to help manage the project, with Sprints lasting generally two weeks, to emphasize agile project principles that will help manage your client's expectations, respond to changes and setbacks, and deliver as much direct value as possible.

Scrum, and good modern programming practices in general, try to create a rhythm to the work and, in this course, the rhythm will typically be:

• Sprint week 1: a written deliverable
• Sprint week 2: a working demo

This does not mean you should do no coding during the first week, just that we will be asking for some evidence of your planning and thoughts during the first week.

Project Deliverables

The following deliverables are expected during the semester:

• Sprint 0 - Discovery (Understand the Problem)
  Choosing a problem and meeting the client
  • Executive Summary
• Sprint 1 - Pretotype (Mockup UI with Navigation)
  Mockup of the project's interface and navigation
  • Team Contract, Version #1
  • User Interview Report
  • Sprint #1 Demo
  • Project Contract
  • Wireframe User Test Report
• Sprint 2 - Prototype (Most Basic Features)
  Basic minimal end-to-end version of the project's most important features to get a quick sense of how it will work
  • Project Plan
  • Sprint #2 Demo
• Sprint 3 - Baseline Prototype (Core Functionality)
  Basic version of the project's core functionality, perhaps using some real data or more robust implementation
  • Team Contract, Version #2
  • Accessibility Plan
  • Design Justification
  • Sprint #3 Demo
• Sprint 4 - Alpha (Partial Full Functionality)
  Basic minimal quality version of as many of the project's features as possible
  • Release Management Plan
  • User Testing #2
  • Test Plan
  • Sprint #4 Demo
  • User Test Report
• Sprint 5 - Beta (Full Functionality)
  Robust version of all of the project's features and design goals
  • License Justification
  • Team Contract, Final Version
  • User Testing #3
  • Sprint #5 Demo
• Sprint 6 - Production (Robust Full Functionality)
  Final version of the project with robust and full functionality, including UI polishing and any updates in response to the Client's User Testing
  • User Test Final Report
  • Technical Documentation
  • Project Handoff

Regular Meetings

Outside of class, we expect you to meet as a team at least once each week and to meet with your client minimally every two weeks. Note, scheduling meetings is difficult with so many people that have different kinds of schedules so plan well in advance when trying to schedule time with your clients or your mentors. The entire team is expected to attend the initial introductory meeting with the client. In general it is strongly encouraged that everyone strive to attend all client meetings, but at least two students must be present for any meeting with a client. For all meetings (with your team, client, or course staff) your team must use this template included in your repository to submit:

• an agenda before the meeting
• a list of who attended the meeting
• a list of the topics discussed (especially if it was something not on the agenda) and any important highlights
• a brief summary of the important decisions
• action items for each team member, including the client if necessary

See these notes on effective meetings. Just like this meme, Open Source software has a saying "Keep a history: if it isn't public, it didn't happen".

Client Sprint Demos

During the week after each Sprint ends, you must meet with your client to show them a working version of the project's progress (i.e., not just test code or working dev tools). It is important to let the customer "drive" the app so you can watch them interact with it; doing the driving yourself while the customer watches is not effective. These meetings are the time to align expectations between you and your client, discuss your progress, get feedback on how well the features implemented match the client's vision, and prioritize the work to be done in the next Sprint.

Note, client demos are separate from the required in class demos.

File Formats

People use a wide array of different devices (Windows, Mac, tablet, or smart phones) to access their information, so you should not send platform specific documents out to team members or course staff. Submit only code, text (.md, .txt, .csv, or .xml), HTML (.htm, .html, or .css), PDF, image (.gif, .jpg, or .png), video (.mp4, .mov, or .avi), or sound (.au, .mp3, or .wav) files. You are free to use any programming environment available to complete your work, however, you are responsible for converting it into one of the standard formats listed above (most current programs can save or print files to a variety of alternate formats).

All deliverables must be pushed to your Gitlab repository by the due date given unless you have made separate arrangements with your instructors and client.

---

Sprint 0 - Discovery

The goal of this initial Sprint is to understand the problem you will be tasked with solving during the semester by meeting your team and your client, learning the project's details, determining what technology makes sense to use, and choosing how your team wants to work together. This is the only Sprint with no public demo.

Executive Summary

This document serves as a short summary of the project that anyone can read to understand what you are creating and why by giving a quick overview of the project for anyone interested (from people thinking about buying it on an app store to someone thinking about funding the project).

In your project repository's Wiki using Markdown format, complete the following sections concisely in about only 1-2 "pages":

• Project Name: Create a "catchy" name for the project. We recommend a short, descriptive, phrase. The client may already have a name or it may take a brainstorming session with the team, client, and users to find a good name.
• Overview. Put this project in context, perhaps including a story or example. What is the problem it is trying to solve? Why does this problem exist?
• Target Users. What type of people or area will this project serve?
• Persona. Develop an example Persona to represent the details of a potential user of this app based on your perception of the Target Users.
• Value. What will be improved or changed by this project? What is its value to its target users?
• Functionality. What is this project going to do?
• Technical Recommendation. What is your rationale for the software and hardware you plan to use?
  For example, consider the following questions:
  • What technology does the client want to use and why (iOS, Android, Web app, etc.)?
  • What technology does the team recommend and why?
  • What expenses might your recommendation incur (especially think about paying for a server, either physically or in the cloud)?

 

Sprint 1 - Pretotype

The goal of this first Sprint is to sketch out a possible app by understanding your users, determining the scope of the features you estimate can be completed during the semester, choosing the roles you want to take on in your team, and forecasting possible outcomes for your team and your project. A Pretotype, or more specifically a working Wireframe, serves to sketch out a possible app by creating a mockup of its interface and navigation that emphasizes "failing fast", doing a simple, quick, demoable implementation to see if you are on the right track.

Team Contract

This document serves as an agreement between all team mates about how the team will operate — a set of conventions that you plan to abide by. It should be created collaboratively by thinking about good or bad aspects of team project experiences you have already had, your goals for the course, how the team should communicate, the quality of work everyone wishes to achieve, and the level of group participation and individual accountability everyone feels comfortable with. It is especially important that each team document how they will maintain project priorities, individual responsibilities, and action items and make them visible.

The process of generating a team contract usually helps jump start a group's efforts to become a team by immediately focusing everyone on a definite task that requires communication and negotiation.

• Discuss this worksheet as a team to get started (if you choose to complete the form, please make a copy of it first into your own Google Drive space)
• Complete this example contract started for you in your project repository's Wiki using Markdown format

By adding this document to your project's repository, each team member implicitly agrees to abide by it.

User Interview Report

This document serves as a summary of your meeting(s) with potential users of this app that captures your understanding of their needs and goals with regards to the problem your app is trying to solve.

In your project repository's Wiki using Markdown format, describe what you learned from talking to potential users, as well as the impact of the project:

• Summary. Summarize your interaction with your potential users, including anything relevant about the setting or existing help for them beside the app you are creating. Note something unique about each user you talked to as well as any common things that were noted by all or most users.
• Process. Describe the process(es) users currently have for solving this problem.
• Assumptions: What assumptions did you have before talking to the users and how did talking to the users help to inform your app design?
• Personas. Develop at least four personas to represent potential users of this app and justify how your personas inclusively capture the wide variety of potential user traits. You may use the initial Persona you developed if you still feel it is relevant.
• Impacts. Describe the contrast between users of this app's current experience with what you expect it to be after this app exists. Refer to your Personas and include justifications and comments from your user interviews where possible.
  Note, impacts can be both positive and negative, inclusive and exclusionary, so be sure to consider possibilities beyond the goal values the client wants to encourage with this app.
  Note, you should work to remove the potential negative or exclusionary impacts when designing and building your app.

Demo Presentation

While having a "running" Wireframe version of your app is encouraged (and fairly easy with modern drag and drop layout tools such as Figma, ExcaliDraw, or WirefraneCC) it is not required — a hand or "PowerPoint" drawn series of "pages" that shows how the app's UI will look and flow is fine.  Note, implicitly, these pages serve as a "contract" with your client of what you intend to implement (or not) this semester, so make sure your client understands this.

During class, your team will have 10 minutes to present a demo as well as key ideas and highlights from this Sprint:

• Problem. the problem your app is trying to solve and a current process used to solve it
• Demo. all the features you intend to try to implement this semester shown with your app's Wireframe
• Personas. two of the Personas you created to represent your potential users
• User Stories. three user stories that provide value to the Personas presented
• Learned. one thing learned so far from your client and one thing from your users (including quotes from them is encouraged)
• Impacts. one possible positive and one possible negative or ethical impact of your app
• Concerns. one possible concern that might impede successful work on your app

Expectations:

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

Project Contract

This document serves as the contract of the project's scope that anyone familiar with the project can read to understand what features you believe you can complete during the semester and why. It helps ensure all parties understand what will be attempted this semester.

In your project repository's Wiki using Markdown format, describe the goals, priorities, and concerns, as well as the team roles within the project:

• Overall Goals and Feature Scope. What features the project will (and will not) deliver, in order to avoid future shifts in the level of ambition. These goals can be anything you have discussed with the client, such as functional, strategic, technological, quality, or ethical. Note, this may involve some negotiation about the team or Client's priorities.
• Design Goals. The overall very high level design of the project, emphasizing the priorities regarding flexibility and maintenance, rather than what classes implement what features. From this section, it should be clear: what features you view as core and integral to the app versus what can be added later, what will be easily changeable in the future and what will require programming expertise, and what changes the client will need to be responsible for in the future.
• Dependencies. Anything the project is dependent on, such as the resources you are expecting from the client or software libraries or frameworks you intend to use to complete the project.
• Concerns. At least three concerns or risks about getting the project done. To help you brainstorm possible issues, do a premortem as a team to imagine ways in which the project might not be a success (here are some common team project issues to consider).
• Team Organization. The external team roles each person will take on and the internal parts of the project each person will focus on (e.g., frontend, backend, data wrangler, etc.) and who will be the backup/understudy for each role.

Wireframe User Test Report

This document serves as a summary of showing your wireframe to potential users that captures your understanding of their feedback on what works and what could be improved. Letting potential users interact directly with your app early and often, while some changes can still be made, is a vital part of the agile process. User feedback can be ambiguous or even contradictory, so it is not this document's purpose to decide how to respond to the feedback — that will likely require a team discussion or a decision by your client.

Meet with 2-3 users and let them interact with your Wireframe in as realistic a way as possible (virtually if necessary). Try to record the meeting or ask each user to summarize their feedback individually after doing the test with you (or the client if you cannot be present). Make sure each user understands the app's purpose (either because you interviewed them earlier or by giving them access to your Executive Summary).

In your project repository's Wiki using Markdown format, describe what the results of testing your wireframe with potential users:

• Results. This should be each user's direct feedback as much as possible (either their written summary or quotes from an audio recording made during the test) rather than your interpretation of their feedback.
• Positive feedback. Summarize the top good things about the app that you feel are important to be kept in the app. Ideally, these would be similar comments made by multiple testers.
• What could be improved. Summarize the top things about the app that users commented critically about, regardless of whether or not you agree with the users or if they seem to contradictory. If any of these comments are made by multiple testers, make sure to note that as well.

 

Sprint 2 - Prototype

The goal of this Sprint is to implement minimal versions of the most highly prioritized features by the client to get a quick sense of how it will work, perhaps what makes the app unique or what is perceived to be most challenging or most uncertain. This Sprint emphasizes rapid prototyping on small example, perhaps hardcoded, data to get something working completely from the backend to frontend. Use this Sprint to also get your first feedback from your users and to clarify what data you need and how you intend to use and protect it.

Project Plan

This document serves to clarify the order in which the project's features will be completed that anyone familiar with the project can read to understand what how the features will be prioritized and who will be taking the lead on each feature. In this comprehensive list, called the Backlog, features should be described as User Stories, that refer to user personas, each of which will be broken down into a set of one or more tasks (Gitlab issues) that you feel confident can get done during a single Sprint. It helps ensure the team understands the client's priorities and demonstrates that the work can reasonably get done.

In your project repository's Wiki, describe the features you intend to complete as part of this project and during which Sprint you expect them to get done.

• User Stories Backlog. Create a Backlog of as many User Stories as you can come up with based on the project's scope determined by your Project Contract.
  Note this Backlog should be updated throughout the semester as new possible features are discussed.
• Feature Deliverables for each Sprint. Based on the scope of the project and your design goals, prioritize general feature sets for each Sprint during the rest of the semester. Your goal for each Sprint is to have a working app to demo to the client made up of related features that provide clear value to the Client, rather than a set of "technical tasks" whose value may be hard to demonstrate in such a way that the client can appreciate. Features will likely include both a user interface component as well as backend support and be reasonably sized enough that you have confidence they can get done during a Sprint.
• Data Needs. Because user data is regularly stolen, sold, or used inappropriately, it is becoming an important issue for both companies, customers, and law makers. Mozilla and other companies have started championing Lean Data practices to minimize what data is needed to run their apps and how long to retain it.
  Justify your user data needs and practices, using your Personas where helpful (this will likely require a team discussion with your client).
• Team Roles for each Sprint. Take responsibility for specific team roles during each Sprint during the rest of the semester. These roles may be fixed, but more likely will rotate among team members during the project.

After reviewing and discussing the features for this Sprint, break down each one into a set of one or more tasks that can be estimated and entered into task tracking software that can be assigned to specific team members and easily updated to track the team's progress. Note, tasks may also be non-programming oriented, but it should be clear from looking at the distribution of tasks that everyone on the team is accepting responsibility for their fair share of tasks overall based on their weekly schedule.

In general, we recommend you follow these steps when managing each Sprint.

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 15 minutes and include a demo as well as some key ideas from this Sprint:

• Demo. a complete Wireframe version updated based on feedback you have received and covering as much of your proposed app functionality as possible to clarify your UX goals
• Delight. describe what you are doing to create excessively positive experiences when using your app: things intended to make users say things such as “That's helpful”, “That was easy”, or “I like that”
• Demo. a working version of the app, showing only complete client facing features and noting who worked on which features
• Value. justify why this set of features was chosen to be implemented first
• Data. justify what, if any, user data is needed by your app
• Personas. two Personas to represent potential users with different data needs
• User Stories. three user stories that provide value to the Personas presented
• User Testing Results. one positive and one critical thing learned from testing your wireframe with potential users (including user quotes is encouraged)

Expectations:

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

Update your project's README file and Tag the commit representing the final version of the code for this Sprint as Prototype_Complete

 

Sprint 3 - Baseline Prototype

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, create a new page that represents your updated Team Contract that reflects 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:

• Persona: Develop two Personas to represent potential users with accessibility needs
• 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
• Personas. the two Personas you created with accessibility needs one and your app supports them
• 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.

Update your project's README file and Tag the commit representing the final version of the code for this Sprint as Baseline_Complete

 

Sprint 4 - Alpha

The goal of this Sprint is to implement a "demoable quality" version of as many features of the project as possible. This sprint emphasizes releasing an "alpha", i.e., buggy but complete, version of the project. At this point, to foresee possible problems in the future, this version must be deployed where the Client can access it on their own (i.e., on their own device or a public web server that is distinct from your development server).

Release Management Plan

This document describes how the team intends to manage the project's software release such that anyone familiar with the project can read to understand how the stable release will be distinguished from the current development version as well as how the project's deployment dependencies (technology, libraries, resources, etc.) are managed. This document serves the purpose of clarifying the packaging and delivery of the elements of a product.

In your project repository's Wiki, describe your plan for the following:

• Release Environments. List all the places you expect the app to be deployed (e.g., app and server, app on multiple platforms, web or mobile app, etc.) and your ideal production environment for each (note, include in your planning the minimal version of the software you can use, i.e., deploying only to the latest version of iOS or Android limits your app to only those users that have upgraded recently or different browser supports). How do you plan to separate the production environment(s) from the test environment(s) (i.e., there should always be a current stable version of your app available to demo)?
• Release Packaging. List the current and expected project dependencies. How do you plan to make them known and easily reproducible for future maintainers (e.g., Docker container, maven or package-info file or other dependency manager, VM, etc.)?
• Release Build Management. What is your pipeline (i.e., process and tools) used for building a development versus a production release? How are these integrated with your GIT workflow (i.e., the branches you merge and pull from and the tags you use)?
• Release Deployment. How do you plan to deploy to each release environment? What parts of the process can be automated and what parts cannot?
• Defect Tracking. How do you plan to track project bugs from open to close? We are not suggesting learning true bug-tracking software, but you should at least make bugs into actual Gitlab issues, using this template, that are fixed in separate commits with separate tests (ideally made before the bug is fixed to better verify the bug and the fix).
• Software Configuration/Change Management (SCM). How will the team collectively determine if a feature is ready to be released or a change (e.g., a bug or security fix or a feature update) should (or should not) be added to the current production release? What is the overall process for managing which features are in which releases, tracking which changes have been applied to which releases, verifying a change works in the current production release, and determining when the current release should be replaced by a new release?

Note, you can use Gitlab to simulate many typical DevOps features using its CI Pipelines to set up containers for your app, to run different commands based on different goals, and only accept Merge Requests on successful completion. Additionally, specific branches can be protected so they can only be accessed using Merge Requests.

User Testing

User testing provides potential actual users with a chance to work directly with your app while some changes can still be made. Thus, focus on parts of the app that are close to finished or that you specifically want tested, i.e., that you want feedback on or are uncertain about. When conducting a User Test, provide potential users with the following information:

• Overview. describe the app, how far along you think it is, what they can expect to see, what kind of feedback you are looking for, and how long you expect the test to take
• Tasks. 2-3 high level, goal oriented, tasks to complete in the app (not step by step directions!). Be concise and clear in describing and motivating your tasks.
• Post-test Survey. an online survey to record feedback from the users. It should be a mix of specific task oriented questions as well as general, open-ended, questions and encourage the users to take some time to experiment with the app in addition to just doing the tasks.

Create an online survey form for your users to take (i.e., Google docs, Survey Monkey, Qualtrics, etc). Depending on the type of survey, you can either create a separate website for the introductory materials or include it as an opening page where they click through to complete the survey. Your site/survey must include the following parts:

• App description. this can come mostly from your Executive Summary
• How to access the app. this may be a web page, a download, or through an online test platform
• Overview of the test.
  • they will do a series of tasks, play with the app in general, and then take survey
  • how much time you expect the survey to take them (at least 30 minutes to encourage them to play with the app after completing the basic tasks)
  • tell users you appreciate their time!
• Tasks.
  • first impressions: give users a chance to report on their interaction with the app
  • series of tasks to complete (again, not step by step instructions)
• Post-Test Survey.
  • consider using the standardized System Usability Scale to evaluate their impressions using your app
  • ask open ended questions that focus more on their impressions of using the app than technical questions
  • end with a general question for anything they want to add, especially bugs they may have found
• Don't forget to thank them for their time!

Encourage your client to participate in the user testing!

User Testing Report

In your repository Wiki, report the results of your user testing with potential users (make sure to clearly distinguish feedback from fellow students in class from that of expected users).

• Results. This should be each user's direct feedback as much as possible (either their written summary or quotes from an audio recording made during the test) rather than your interpretation of their feedback.
• Positive feedback. Summarize the top good things about the app that you feel are important to be kept in the app. Ideally, these would be similar comments made by multiple testers.
• What could be improved. Summarize the top things about the app that users commented critically about, regardless of whether or not you agree with the users or if they seem to contradictory. If any of these comments are made by multiple testers, make sure to note that as well.

Test Plan

This document describes how the team intends to verify the project's quality such that anyone familiar with the project can read to understand how features will be tested, with both expected and unexpected input/interactions. This document serves the purpose of ensuring the team is committed to providing a high quality working project.

In your project repository's Wiki, describe the how you plan to use to test this project.

• Test scenarios. List as many test scenarios as you can think of for each feature.
• Definition of Done. How will you verify features are complete and working in a replicable manner? Note, strategies may differ across features (e.g., some may be automated using different tools, but some may need to be manual)?
• Resources. What do you need to support your tests (i.e., data files, scripts, mock databases, etc.)?

Test Scenarios

A scenario describes one or more steps necessary to test how each feature is used within your app by thinking about possible users actions and objectives for different possibilities, including those resulting in naive errors and those due to abuse based on users with hacker's mindset. A feature may have as little as two test scenarios (one positive and one negative) to a tens of scenarios depending on its complexity. There are many types of test scenarios at many different levels of the application, some of which can be easily automated but some of which may not be. For automating testing, we suggest using Cucumber scenarios for each feature.

The following should be included in each test scenario:

• Label or ID
• Feature (what one feature is this test for)
• Purpose (what is this scenario testing)
• Preconditions (assumptions before test starts)
• Steps (using Gherkin)
• Post-conditions (expected outcome)

As many of these tests that can be automated should be converted to code that will be regularly run against the current version of your app using Gitlab's Continuous Integration Pipeline and an appropriate tool for showing your tests' Code Coverage (strive to achieve at least 70% lines covered by tests).

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, deployed, 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
• Project Architecture Diagram(s). show visually the high-level design of your project to highlight the organization of your components and flow of data through the software
• Testing Results. demo the results from running your automated tests, highlighting at least two negative path tests and showing Code Coverage results, and describe one manual test you do regularly
• Release Management. describe how you distinguish your stable production app/environment from your test or development app/environment in your development process (including within your GIT workflow)
• User Testing Results. one positive and one critical thing learned from user testing your app with potential users (including user quotes 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)
• Retrospective. one thing that worked, one thing that did not, one thing you added or changed about your Team Contract, and one concrete thing you plan to improve next Sprint about your teamwork/process and how you will determine whether or not actually improved
• Planning. the features 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.

Update your project's README file and Tag the commit representing the final version of the code for this Sprint as Alpha_Complete

 

Sprint 5 - Beta

The goal of this Sprint is to create a robust, complete, version of all the project's functionality. After this sprint, no new features should be added — just bug fixes and changes made in response to user feedback. At this point, the app must be deployed in the Client's environment to prepare for the final hand-off.

License Justification

This document describes how this project's code can be used going forward after you leave the project, such as: how your names will be associated with it, how much it can be modified, what kinds of other code it can be used with, and what kinds of things it can be used for. This document serves the purpose of clarifying these issues because experienced developers will not touch unlicensed code because, technically, they have no legal right to use it. This can be a complicated choice, with a variety of competing goals, because there are significant differences between Open Source licenses.

In your project repository's Wiki, justify your choice of license for your app (Open Source, Proprietary, or otherwise) as follows:

• Open Source Licenses. if your app makes includes any code you did not write (i.e., from GitHub, examples or tutorials, non-standard libraries you depend on, etc.), list them and their licenses
  You can scan your project on Gitlab to show its dependencies.
• Team Preference. which license does the team want to use and why
• Client Preference. which license does the client want to use (or do they not have a preference) and why
• License Choice. which license did the team and client agree to use
• License Text. include the actual text of the license (this should be standard boilerplate text that you can get from the official Open Source license page, from an example Proprietary license, or from your client -- do not attempt to write a license on your own)
• Justification. explain the implications of your choice with regards to how the code will be used going forward and how that justifies the final choice

Final Team Contract

This document serves as an agreement between all team mates about how your team will operate, a set of conventions that you plan to abide by, now that your team is more comfortable working together. This final version should be something the team would feel good about using to guide it if the project were to continue on next semester (so that it captures both what has worked to make the team successful and ways to improve what is still not working).

Revisit your updated Team Contract in the project's Wiki based on the readings and class discussions relating to ethics to develop a code of conduct and values your team wants to uphold. Meet as a team to share your individual experiences and views on ethical topics from this semester to determine where your values align and differ — remember, ethical issues especially do not have right or wrong answers so make sure to practice empathy, understanding, and trust in trying to understand and value everyone's opinion. While you are not expected to agree on everything, as a team you should be able to create a reasonable compromise that everyone can accept.

In your project repository's Wiki, create a new page that represents your final Team Contract that reflects your team's collective ideals for dealing with thorny issues that occur.

By adding this document to your project's repository, each team member implicitly agrees to abide by it.

Final User Testing

This is your final chance to get feedback from users so it partly an attempt to get feedback and partly an attempt to determine how successful your effort this semester was.

Create a new online survey form for your users to take (i.e., Google docs, Survey Monkey, Qualtrics, etc) that does not assume they took your previous test and update the app information and tasks you want feedback on. Depending on the type of survey, you can either create a separate website for the introductory materials or include it as an opening page where they click through to complete the survey.

In your project repository's Wiki, include the raw, exported survey results from the users that took the survey as well as the following text displayed in the site/survey you create:

• App description. this can come mostly from your Executive Summary
• How to access the app. this may be a web page, a download, or through an online test platform
• Overview of the test.
  • they will do a series of tasks, play with the app in general, and then take survey
  • how much time you expect the survey to take them (at least 30 minutes to encourage them to play with the app after completing the basic tasks)
  • tell users you appreciate their time!
• Tasks.
  • first impressions: give users a chance to report on their interaction with the app
  • series of tasks to complete (again, not step by step instructions)
• Post-Test Survey.
  • ask open ended questions that focus more on their impressions of using the app than technical questions
  • end with a general question for anything they want to add, especially bugs they may have found
• Don't forget to thank them for their time!

We may do a dry run of your tasks during class but also give your survey to a friend, and us, for feedback before giving it to the client.

Demo Presentation

Since this presentation serves to wrap up the project, it should show what your team, and each individual, has learned during the semester.

Your presentation should be limited to 20 minutes and include a demo as well as team and individual reflections from the semester:

• Elevator Pitch. clear and concise description of the problem your app is trying to solve (no more than 40 seconds!)
• Demo. a working, deployed, version of the app, that shows the complete set of final client facing features
• License Choice. explain which license your team and client agreed to for the app and why it was chosen
• Persona. present two new Personas and how your app handles them: one that is adversarial in some way that actively tries to break or infiltrate your app and one that has ethical concern(s) about your app
• User Testing Results. one positive and one critical thing learned from user testing your app with potential users (including user quotes is encouraged).
  Share one thing each person learned during the semester from interacting with potential users and responding to their feedback.
• Testing Results. demo the results from running your automated tests, showing Code Coverage results, and describe one manual test you do regularly as well as results from an Accessibility checking tool
  Share one thing each person learned or changed by testing their code regularly.
• App Review. contrast the completed app compared to where you planned it to be in your initial Wireframe and Project Plan and how you have worked to make the app as inclusive as possible and reduce potential negative outcomes.
  Share one non-technical thing each person learned during the semester by working iteratively on your app or with your client.
• 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)
  Share one thing each person learned or changed by trying to estimate and plan their work using tools, such as Issues and Milestones.
• Retrospective. reflect on what has worked to make your team successful and what could still be improved: highlight changes made to your Team Contract and how those did (or did not) help foster teamwork; and what concrete experiments you took to try to improve and how they helped (or not) your team's communication and velocity.
  Share one thing each person learned or changed by using the Agile process to manage the coding process.
• Team Review. describe the ways your teamwork process and communication have improved during the semester and one thing that could still be improved.
  Share one thing each person learned during the semester about creating a positive team culture.

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.

Update your project's README file and Tag the commit representing the final version of the code for this Sprint as Beta_Complete

Sprint 6 - Production

The final version of the app should have robust and full functionality, including any updates in response to User Testing, and the final documentation to help the Client manage the software after you leave the project.

Final User Testing Report

In your project repository's Wiki, report the results of your user testing with potential users:

• Results. This should be each user's direct feedback as much as possible (either their written summary or quotes from an audio recording made during the test) rather than your interpretation of their feedback.
• Positive feedback. Summarize the top good things about the app that you feel are important to be kept in the app. Ideally, these would be similar comments made by multiple testers.
• What could be improved. Summarize the top things about the app that users commented critically about, regardless of whether or not you agree with the users or if they seem to contradictory. If any of these comments are made by multiple testers, make sure to note that as well.
• Developer Responses. Describe any ideas to improve the app based on user's feedback.

Technical Documentation

This documentation contains all the information the client needs to use, maintain, and upgrade the app after your team has disbanded — it should reflect the current state of the project, not an idealized or bug free version. It is fine to copy, and update, from versions of documentation created earlier in the semester if it is relevant.

1. Within your app, include an About Page that includes your names, clients' names, Duke University, and any other supporters your client has had in their research (ask if you are uncertain)
2. Within Gitlab, at the top level of your repository, include the following basic files:
   • Icon.png. image for your project logo (whether or not it is a mobile app)
   • README.txt. file that explains your project's purpose, its dependencies, and an overview of how to deploy your project
   • RELEASE_NOTES.txt. file that lists your project's current functionality, including any known bugs, assumptions, or limitations, and what platforms it has been tested on (including version of OS, Browsers, etc.)
   • BACKLOG.txt. file that lists future features you would like to implement (it is a bad sign if this file is empty!)
   • LICENSE.txt. file that includes the license text your team chose for the project
3. Within Gitlab, in a separate folder called doc, include three kinds of documentation for different audiences (these may be multiple files in different formats):
• User Documentation. for non-technical users of the app in the form of HowTo Videos, Help Files, FAQs, notes about assumptions or expectations, etc.
  Note, if this is built into the app instead, that must be noted in the doc folder.
• App Maintenance Documentation. for technical IT managers responsible for the installing and maintaining the running app in the form of:
  • install instructions, especially requirements or assumptions about the target environment
  • list all open source tools or libraries your project uses, their versions, and links to their associated licenses
    Note, if this is included in a standard file as part of your project's build process (like pom.xml or package.json), that must be noted in the doc folder.
  • data changes, address ways to update or change key non-programming components of the app, such as database information, data files, resource links, phone numbers, server addresses, etc.
    Note, do not forget to include necessary account and password information!
• Technical Documentation. for programmers that need to modify the app in the form of comprehensive project code design documents, including:
  • in-code comments (especially your names within every file!)
  • database schema (you can generate a diagram from your database)
    Note, if a single, complete, view of this is built into the app instead, that must be noted in the doc folder
  • overall architecture design (you can generate a diagram from your code), including things like what you intended to be flexible, how you intended new features to be added, or why you separated the client/server logic the way you did
    Note, do not forget to include justifications for your primary design decisions!
    

Your project must include precisely how to rebuild your app's server (if you have one) directly rather than relying on written instructions. You can do this using these options (in order of preference):

• create a shell script or, specifically a Docker script, that can generate your environment
• export a VM (a VMDK or OVF image)
• provide SSH login access to a cloud VM you have set up (like Duke's VCM, Netlify, or AWS)

Update your project's README file and Tag the commit representing the final version of the code for this Sprint as Production_Complete

Project Handoff Meeting

As your final deliverable, schedule a Project Handoff meeting with your Client that will likely take 30-60 minutes:

• Demo any new features/changes done that the Client has not seen (or show the entire app if requested by the client)
• Present the final User Testing feedback: especially any ambiguities you feel should be discussed and any resulting recommendations you have that were not able to be implemented
• Explain what the Client will need to run the app after the handoff
• Go over all of the documentation: do not read all of it directly, but make sure they understand the important highlights (like the License, how to make data changes, significant design justifications, etc.)
• Answer any questions from the Client

In planning your meeting, note:

• Everyone on the team is expected to attend this final meeting
• At least one person from the course staff must attend this final meeting
• All code/documentation changes must be complete before this final meeting
• Work out exactly how to get the code to the client and, ideally, give it to them at the meeting instead of promising it later (even if it means using a USB stick)