Menu Expand Search
CS4530, Summer 2025

Preliminary Project Plan Due Wed, May 21 at 6:00pm Boston time

Generative AI tools may not be used for this assignment and must be turned off in any text editors you are using. You are expected to make a good-faith attempt to avoid reliance on “AI Overview” features in search engines, and to verify anything you see there with authoritative sources.

All projects will involve frontend and backend development of new features for the Strategy.town website, will take place in the TypeScript programming language, and will involve using React for the user interface. You and your team will decide what kind of new features you would like to build. Your features should be something that can be implemented within the timeframe allotted (3 weeks, plus 1 week of planning), and will be implemented in a fork of the main codebase. (Your starting point will be the same as the starter code for the third individual project, which is the same as the final code for the second individual project with Task 2 completed.)

In coming weeks we will provide instruction on how to deploy the application to the cloud. The first three individual projects are designed to get you up-to-speed on the Strategy.town codebase and introduce you to TypeScript, React, NodeJS, and testing frameworks, and you now know how to run the entire application in the local development environment. Given this introduction, and given that you will have a team of four, we expect that the features that you propose will be more complex than the features implemented in the individual assignments.

Feel free to look at existing systems with forums (like StackOverflow and Reddit), systems with multiplayer gameplay (like lichess, one million chessboards, or Tabletopia), and systems for chatting while watching real-time events (like Twitch and YouTube Live) for inspiration. Examples of features that students might propose include:

Multiple teams might propose the same feature, or a variation of that same feature - this is expected and is not a problem.

When considering your project, please keep in mind that you will be allowed to publicly post your project online: while your immediate audience for the project is the course staff, if you are ultimately looking for software engineering jobs or co-ops, this project can be a useful piece of your portfolio. (You should therefore be careful about the use of trademarks — while it is legal in the United States to create a game that works like the Hasbro board game “Battleship,” you want to avoid publicly posting a game that uses the trademarked name “Battleship.”)

Overview

The project plan will include:

You should plan on spending the time between now and Wednesday, May 21 in a “Sprint -1” in which you will undertake organizational and research tasks to help you decide on a project and formulate your plan.

You should be in contact with your assigned TA mentor before you submit the project plan so they can answer questions and make sure you are on the right track. You may wish to share a draft of your plan with them before the deadline to get early feedback; Tuesday in class will be a designated time to do this.

Each team will self-organize, as agile teams should, and will enhance and adapt their plan during the project lifecycle. As such, the primary goal of this document is to begin the planning process, and not to produce a detailed plan that must be followed precisely. The course staff will provide regular feedback on your project to help ensure that the scope of your project is appropriate.

Details

We list page maximums for each section as general guidance of what we are willing to grade. Please do not feel compelled to use all of the pages provided, and remember that a diagram or table can be as expressive (or more) as a comparable amount of text.

Problem Statement (max 1 page)

Your project plan should begin with a 1-3 paragraph introductory problem statement: how would you describe the overall problems with Strategy.town that your (proposed) features solve? Provide a clear description of the feature or features you are proposing. For example, if you are proposing a “secure chat” feature, explain what you mean by “secure”.

In the project plan review meeting on May 22, you will be asked to distill this down even further into a simple sentence, something like the “twitch for correspondence chess” pitch that we’ve used to describe Strategy.town.

User Stories and Acceptance Criteria (max 3 pages)

Given the problem statement, develop exactly 3 user stories that show how a user would interact with the features. User stories are requirements specified in the following format

These user stories should be numbered (1), (2), and (3). In the project plan review meeting, you will be asked to distill each of these user stories into just a few words, and you will be expected to defend how your user stories are connected to your overall proposal and to the specific features you plan to implement.

Each user story should include conditions of satisfaction numbered (1.1), (1.2), (1.3), etc. Please make sure that your conditions of satisfaction cover all the common cases and can be turned into testable behaviors. Each user story and condition of satisfaction must have a priority (Essential, Desirable, or eXtension). The set of Essential items will constitute the “Minimum Viable Product”.

Your document must contain a table listing user stories, conditions of satisfaction, and priorities.

Roles

For the purpose of this project, a role specifies a set of connected needs and desires inhabited by people who are not directly involved in the project’s implementation. People can inhabit a role from time to time (“card game enthusiast,” “forum moderator,” “site administrator,” “surveillance expert at a shadowy government agency that has served a national security letter to Strategy.town due to what they claim is its popularity with groups of people that are considered terrorists by the current government,” “advertiser,” “subway commuter,” “parent of a college student”) or more permanently (“mobility impaired person,” “colorblind person”).

Capabilities, Benefits, and Features

Remember that features are not capabilities or benefits, and that working with user stories should prompt you to revisit the features you plan to implement. Your problem statement may (and probably should) discuss features that you want to implement, and your conditions of satisfaction will definitely need to discuss some specifics of features.

Some of the suggested features above are primarily about some non-functional quality of the code base and have little or no user impact. If your group is strongly interested in exploring a non-functional requirement, then your third user story is allowed to use “Strategy.town product owner” as a “role” that is invested in the long-term trajectory of Strategy.town as a piece of software. The capability and benefit must be well-defined and not overly broad, and the user story must have some relationship to the other user stories via the problem statement. This is not leeway to explore a grab-bag of disconnected non-functional requirements. (As an aside, there are certainly people who see these “internal” roles as valid components of user stories, see this blog post for example.)

Work Breakdown (max 10 pages)

Given the project concept that you have chosen and the functionality that you expect to implement to satisfy your user stories, define a breakdown of the work that will be necessary to complete the project.

A work breakdown includes all of the tasks necessary to accomplish the project, and will be an artifact that we will refer back to throughout the project to evaluate whether you are making satisfactory progress. Consider all of the kinds of tasks that your team will need to perform, including knowledge acquisition, design, implementation, testing and documentation tasks. It is hard to say (generically) how many work items are necessary.

Each task on the work breakdown should be assigned to exactly one team member (as primary responsible party), who should provide a “T-Shirt” estimate for how long it will take (along with a justification for that estimate). Consider the dependencies between tests: perhaps an API needs to be designed and specified before implementation can begin; perhaps your development environment needs to be configured before anything else can proceed. Assign tasks to sprints considering these dependencies.

Given the preliminary nature of your plan, we do not expect that you will know all of the details about precisely how to implement your feature such that you could break it down into tasks that you feel could be implemented in a day or two. Large tasks (those which you can not provide a responsible estimate for) must be accompanied by smaller “research” tasks that can be performed early on in the project. You may wish to provide deadlines by which the task must either be refined into smaller tasks (based on new knowledge gathered), or reworked/abandoned.

Consider if you were proposing a feature for running video advertisements when games complete, without the experience of having completed it. It might be difficult to consider how to break down a task like “Implement the frontend components for ad video playback” into something that you could commit to doing within a day or two. Given that this is a task that can be delayed until the end of the project (no other tasks depend on it), it would be wise to consider having some tasks early on in the project, such as: “Find react components that embed video ads,” and “Implement simple video player that does not synchronize playback.” Completing these smaller tasks early would let you both demonstrate that some forward progress is being made, and also allow you to create a much more responsible estimate for how that last, otherwise insurmountably large task would take.

Do not wait for your TA feedback to begin this work. You probably know more about the details of your project then they do. It will be helpful for all concerned if your Project Plan lists the major unknowns or things that you expect to need help with — this will help the TA provide more useful feedback for you

Be realistic, and leave time for contingencies (including the time around the midterm exam). Remember that you will need to have a short demo the week before the project deadline — three weeks from the deadline of this assignment — and will present a full demo 4 weeks from the deadline of this assignment. If you are uncertain that some tasks will be feasible, then be sure to include evaluation tasks earlier-on in the project that will allow for “go/no-go” decisions to move forward on a task or drop it.

We understand that we are asking you to do something — estimating the technical complexity of a new project — that is difficult even for experts. We will provide you with feedback on this preliminary project plan, which you will use to produce a revised project plan (due 6 days later, on the Tuesday after your Thursday in-class review of this proposal). Throughout the project period, teams will meet regularly with their dedicated TA Mentor, who will help track progress on a week-to-week basis and help to determine when adjustments to the project scope are needed.

Each work item should contain the following information:

Your work breakdown may take the format of a simple textual list or a table.

Submission

Your project plan should be submitted as a single PDF in Gradescope to the assignment “Preliminary Project Plan.” Each team submits a single document to Gradescope.

Grading

The project plan will account for 10% of your project grade, and will be graded out of 100 points. The grading of the project plan is further broken down as follows:

Introductory problem statement (5 points):

User stories (30 points):

Your user stories taken together will account for 15% of your grade on this assignment. Each user story will be graded as follows:

The user stories must be numbered (1,2,3) and each the conditions of satisfaction must likewise be numbered (1.1, 1.2, 1.3) and laid out in a table for easy reference.

Remember that you will get full credit for delivering a minimum viable product (MVP) only if you deliver working implementations of all of your essential user stories and conditions of satisfaction. To receive full credit in the project as a four-person team, you must implement MVP AND all desirable conditions of satisfaction.

Work breakdown (50 points):

Your work breakdown will be evaluated holistically on the following rubric:

Coverage of tasks needed (25 points):

Receive full marks if the work breakdown includes all (reasonably expected) tasks to implement your feature, considering these kinds of tasks:

It is not possible to state generically for all projects whether all of the above types of tasks are necessary. However, we believe that this list is exhaustive (we do not expect other kinds of tasks).

Assignment of tasks (5 points):

Receive full marks if:

Sizing of tasks (15 points):

Receive full marks if each element on the work breakdown:

Scheduling of tasks (5 points):

Receive full marks if each element on the work breakdown:

Participation in project review (15 points)

The final 15 points will be based on participation in, and engagement with, the in-class review of the preliminary project plan on Thursday, May 22.