Project Deliverable 3

The project is in full swing now. Kudos to everyone for getting started early! I hope everyone has fun and gains a lot of valuable experience. The TAs and I are here to help you achieve both of these goals.

In class we talked about how an Agile team works on a software development project: the process, the roles, etc., in great detail. The project is where you put all this knowledge in practice. This document outlines how your work will be assessed.

Product Backlog

By the time of the submission, you should have gone through two sprints at least or more. This means that you have started to work on your user stories.

After a sprint, you might have decided to change either the personas or the user stories before going to the next sprint. Therefore, you should provide a new version of these personas and/or user-stories (and so the version number of these documents should evolved). In addition, you should provide an explanation about what has changed between the two versions.

Sprint Backlog

Each sprint should have its own sprint backlog. For this deliverable, you should have at least two sprints fully documented. Each sprint backlog should contain:

• tasks: each task should have a brief description, story points and dependencies if any. In addition, each task should come with a detailed description that contains all kind of useful information that will be used by the developer while working on this task. This detailed description is the result of the team brainstorming on what the result of this task should be. It could include technological choices, third-party tools and APIs, documentation, UI design sketch, UML specification or any description of the code structure, pseudo-code, testing strategies and so on and so forth.

• sprint plan: the detailed task allocation plan of who will do what and when during that sprint.

• sprint report: that shows what happened during the execution of the sprint.

• burndown chart: that shows the provisional and the actual progress of the sprint.

Source Code

By the time this deliverable is due, you should have a significant chunk of your system working. This means that you should have several working releases corresponding to completed user stories.

The source code should come with clear instructions about how to build and run your code. The course staff will run these working releases and check whether they match the product and sprint backlogs. Moreover, you will be asked to build and run your code from a fresh checkout of your Github repository during the interview.

Presentation and Quality of Writing

Similarly to previous deliverables, feel free to choose how to organize and present your deliverable. Make sure that it looks professional and is very easy to read. The TAs will not have much time and you need to convince them you did an excellent job! The following will always be considered when grading your work in this course:

• Presentation: the deliverable is well organized, formatted, looks professional, is easy to read and to navigate.
• Quality of writing: language, grammar, clarity, professionalism.

Submission

Submit the product backlog, the sprint Backlog(s) and the source code by pushing them into your team’s GitHub repository by the due date and time. In addition, the source code of your product should also be on your team’s GitHub repository. Make sure to include instructions about how to build and execute your product. The TA will look carefully at your code and execute it to make sure it matches your product and sprint backlogs.

Additionally, update your team’s GitHub repository README file to reflect the progress on your project.

Coming next

There is no deliverable for this part.

As a team, you should start thinking about how you are going to verify and validate your product.