Design Capstone Project

Over the course of the semester you will work as a team using the Scrum software development process to build a significant software system for a real customer. You will learn to collaborate with your development team and a customer, manage a software development process to build quality, requirements-driven software on a definite schedule, and to build the software to meet the needs of a real-world customer.

Before you begin work on your projects, please complete and sign the Team Contract.

How it Works

As a reminder, there are three (classes of) members of a Scrum team:

Consult the course slides for details.

The heart of the Scrum process is a series of iterations called Sprints, which in this course will last three weeks each. Each Sprint delivers a successively more complete subset release of the final product and consisists of the following activities:

Deliverables

Beginning of Project

By the end of the first week of the project, send me a one-page product vision document and create your epic stories in Pivotal Tracker.

Sprint Deliverables

Rather than having separate deliverables for planning, requirements, design, test plans, implementation, and so on, you will maintain clean source code repositores and actively use Pivotal Tracker for stories, planning and functional tests. You'll send me a report at the end of the first and third week of each sprint, due on Friday via email to me at chris.simpkins@gatech.edu, which summarizes the information in Pivotal Tracker and your source repo. One member of your team should send the report, and the body of your email should contain your team number and list the members of your team (for my convenience).

Each sprint is three weeks in length, and at the end of first and third week of each sprint you'll deliver the following:

Week 1: Sprint Planning Report

Send me an email with a PDF attachment named team<N>-sprint<M>-planning.pdf, where N is your team number and M is the Sprint number (e.g., team1-sprint1-planning.pdf), containing the following:

  • Planning activities undertaken by Scrum Team
    • Meeting with customer - date, time, attendees, activities
    • Meeting of dev team for design and task assignments - date, time, attendees
  • Stories planned for this sprint
    • New stories
    • Stories are carried over from previous sprint
  • Planned velocity for this Sprint with justification
  • Evidence of design for this Sprint's stories (e.g., photo of whiteboard of UML)

I will grade Sprint Planning by:

  • Matching your Sprint Plannig Report to your team's Pivotal Tracker project
    • Each story should be linked to an Epic
    • Each story in the "Backlog" panel (Product Backlog) should have an estimate
    • The estimates for stories in the "Current" panel (Sprint Backlog) should add up to the Sprint's planned velocity
  • Ensuring that functional tests are integrated into each story's description

Week 3: Sprint Review Report

Send me an email with a PDF attachment named team<N>-sprint<M>-review.pdf, where N is your team number and M is the Sprint number (e.g., team1-sprint1-review.pdf), containing the following:

  • Review activities undertaken by Scrum Team
    • Meeting with customer - date, time, attendees, activities
  • Stories completed
    • A story should not be accepted if any tests fail.
    • Accepted means the functional tests pass.
    • If a story is accepted but the tests fail, you will lose points.
    • If a story does not have test, or sufficient tests, you will lose points.
  • Stories planned but not completed and why:
    • Underestimated
    • Rejected by customer
    • Not delivered to customer due to failing unit or functional tests
  • The software release for the Sprint
    • Ideally a link where I can download and install, or run your software
    • May be email attachment or even physical media, like a CD
    • Should be delivered to me the same way it will be delivered to users

I will grade Sprint Review by:

  • Matching your Sprint Review to your team's Pivotal Tracker project
  • Updating your project source, building and running your software and performing the functional tests
  • Looking at your code to assess coding standard compliance, appropriate effort level, team engagement, etc.
  • Comparing your design from Sprint Planning to your implementation
    • Implementation doesn't have to match perfectly (rarely does), but there should be a connection between your initial design and final implementation

End of Project

At the end of the project, you will receive a grade for each of the following: