Projects
All projects in this course are sprints in a semester-long effort to create a usable piece of software for a client. These sprints will be done in teams of four or five. Students are permitted to select their own teams, which will be fixed for the entire semester. Students should select their teams through Brightspace.
Initial Product Backlog
Before the sprints can begin, each team must create an initial product backlog. Although the contents of this backlog will eventually be added to Trello, the initial backlog must be provided as a Word or PDF file in a docs folder in your GitHub repository.
At the top of this backlog document, write a single sentence describing, as clearly as possible, the product vision. This vision is a short statement of what the entire product is supposed to do.
Next, the initial backlog should contain a listing of all major features the product should have and an estimate of how much work each one is. The backlog items are not yet sprintable stories; thus, the estimates of effort will likely be fuzzy. I recommend using the following levels:
- Very Low: A few days to implement
- Low: Less than a full sprint to implement
- Medium: Takes a full sprint to implement
- High: Takes multiple sprints to implement
There are many guides on the Internet to creating a product backlog, but this blog post gives an overview of the process with a number of good ideas to keep in mind for future refinement and creating sprintable stories.
Initial Product Backlog Grading
| Criteria | Description | Weight |
|---|---|---|
| Product Vision Statement | Meaningful, succinct statement of product goals | 25% |
| Product Backlog Items | PBIs covering all major features of the product, with reasonable effort estimates | 75% |
Sprints
Sprints each have a length of two weeks and will follow the schedule below:
| Sprint | Start Date | Due Date |
|---|---|---|
| 1 | 1/27/2025 | 2/07/2025 |
| 2 | 2/10/2025 | 2/21/2025 |
| 3 | 2/24/2025 | 3/07/2025 |
| 4 | 3/17/2025 | 3/28/2025 |
| 5 | 3/31/2025 | 4/11/2025 |
| 6 | 4/14/2025 | 4/25/2025 |
One member of each team is the Product Owner. Another member of the team is the Scrum Master. All other members of the team are Developers. Below is a table listing the duties of each role.
| Role | Duties |
|---|---|
| Product Owner |
|
| Scrum Master |
|
| Developer |
|
Because your teams are small, Product Owner and Scrum Master are not full-time positions. In other words, the Product Owner and Scrum Master are expected to use 50% of their time doing their own roles. During the other 50% of their time, they should be working in a Developer role.
Sprint Grading
Each sprint will be graded according to the following criteria. The Source column describes the source of the data used to determine the score. Even if they're not ready to sprint, all cards in Trello should have an effort estimate and a priority. If some cards are dependent on other cards as prerequisites, that should be noted as well. Sprintable stories should have acceptance criteria so that it's possible to be sure when each story has been completed.
| Criteria | Description | Source | Weight |
|---|---|---|---|
| User Stories Selected | Selecting high-priority user stories | Trello board | 10% |
| User Stories Completed | Completing user stories selected for this sprint | Trello board | 20% |
| Quality of Implementation | Writing effective and efficient code with good style and formatting | GitHub repository | 30% |
| Testing | Providing appropriate tests for completed user stories | GitHub repository | 10% |
| Client Satisfaction | Meeting the client's expectations | Direct communication between instructor and client | 10% |
| Review | Review with client is done to assess state of the product and decide the direction for the next sprint | Sprint review document | 10% |
| Retrospective | Team retrospective is done to assess what went well on this sprint and what could be done better in the future | Sprint retrospective document | 10% |
Product Owner Grading
The grade for Developers will be a weighted version of the sprint grade. 50% of the Product Owner grade will also be a weighted version of the sprint grade, but the remaining 50% will be based on the following criteria:
| Criteria | Description | Source | Weight |
|---|---|---|---|
| Client Communication | Communicating with the client throughout the sprint process | Direct communication between instructor and client | 15% |
| Updating PBIs | Adding, removing, and refining PBIs based on client and team feedback | Direct communication between instructor and client as well as team feedback on Sprint Reflections | 20% |
| Documenting Sprint Review | Reporting what the goal of the sprint was, why it was important, what stories were completed, and what stories were not completed | Sprint review document | 15% |
Scrum Master Grading
Like the Product Owner, 50% of the Scrum Master grade will be a weighted version of the sprint grade, and the remaining 50% will be based on the following criteria:
| Criteria | Description | Source | Weight |
|---|---|---|---|
| Team Organization | Making sure that everyone on the team has something to work on and ways of overcoming challenges that are preventing work | Team feedback on sprint reflections | 12.5% |
| Story Poker | Running the story poker session to select stories and estimate their point value | Team feedback on sprint reflections | 12.5% |
| Updating Trello | Updating Trello to assign team members to user stories, to record story point values, and to mark stories done | Trello board and team feedback on Sprint Reflections | 12.5% |
| Documenting Sprint Retrospective | Reporting what went well about the sprint, what went poorly, what new ideas the team has, and what actions the team will take to have better sprints in the future | Sprint retrospective document | 12.5% |
Turning in Projects
Teams are responsible for dividing their workload. Each member of the team will receive a grade for each project based on the overall grade, weighted by that member's participation. The files for each submission should be part of a tagged release on a private repository on GitHub created before the due date. Each release is due before midnight on the last day of each sprint. If the project is late, the group will receive a score of 0.
The tagged release must include a zipped archive containing the following deliverables:
- Current source code, including tests
- Compiled executables (if appropriate)
- Sprint review document
- Sprint retrospective document
Sprint Review Document
Although the sprint review document is necessary for every sprint, it does not have to be long. It must list the following, in a readable format:
- Goal of the sprint
- Why the goal was important
- What stories were fully completed
- What stories were not completed
- Client feedback
Sprint Retrospective Document
Like the sprint review document, the sprint retrospective document does not have to be long or complicated. It must list the following, in a readable format:
- What about the sprint went well
- What about the sprint went poorly
- What new ideas the team has
- What actions the team will take to have better sprints in the future
Sprint Reflection Form
In addition to the deliverables provided by the group for each sprint release, each team member must complete a sprint reflection form. A blank form is provided below:
This form must be turned in individually by every team member for every sprint via Brightspace. These reflections are confidential and allow students to communicate to the instructor how teams are functioning. The ratings on the sprint reflection form are used to weight the contributions to the sprint grade as well as provide feedback on the Product Owner and the Scrum Master. Each sprint reflection is due by midnight on the Monday following the end of a sprint. Sprint reflections are graded for completion only.
Final Presentation
During the time scheduled for the final exam, your team must demo your project for the class and for the clients. You should give a brief overview of your product, explain its purpose, show off its most impressive features, and take questions. Your presentation should be polished and smooth and take about 10 minutes. Use of a presentation tool such as PowerPoint is expected. Team members who do not participate in the final presentation will score a 0 on it.
