Project Deliverable 4

You have planned and re-planned and re-planned. And hopefully, your plans got more accurate with each attempt. In addition, you should have the most part of your product working and fully tested.

Product Backlog

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.

Going through your first sprints means that you have decomposed the first user stories into tasks. Therefore, your product backlog should contains a list of tasks associated with user stories. 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 Backlog

By the time of the submission, you should have gone through several sprints. Each sprint should have its own sprint backlog that contains:

• 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 now, you should have the most part of your product 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.

Verification and Code Review

You will need to convince us (and yourselves!) that it works. In this deliverable, every piece of code that goes into the product needs to be tested and inspected. As discussed in class, you should have, at least, two types of tests:

• unit-tests/integration-tests in which you are testing relatively small components of your product. These tests must be fully automated.
• acceptance-tests in which you are testing user stories. In the best effort, these tests should be automated. If the test cannot be automated, at least, there should be a document explaining in detail how to manually test the code.

Moreover, you should have all of the documentation related to your code review activity. This means:

• code review strategy: your team’s guideline to conduct the code review
• code review summary: a completed code inspection summary from each team member
• code review debriefing meeting: a 3-5 minutes video of your code review debriefing meeting where each team member gives general recommendations to the team on how to improve the quality of the development.

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 might will likely take a look 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.

Get ready for the final report and deliverable. We will ask you to deliver the final working version of your product and a reflexion report about your journey through the project.