I wanted to follow up on last week’s announcement with some generic feedback and guidance for the project sprints.

Sprint 1 Retrospective

The most significant issue in the first sprint was that no team had their specification and implementation accepted by the end of the sprint. In the real world, you would have missed a release deadline and now have an angry customer on your hands! Consequently, the grades on the first sprint (specification, implementation, and retrospective) ranged from 50–80% across the teams.

One issue that most groups highlighted in their retrospectives was not allotting sufficient time for the review process. In real software engineering projects (think software being developed by tech giants like Microsoft, Google, and Amazon), quality is paramount, and software changes typically require extensive testing and review. You’ll note that the “soft” deadlines for the specification and implementation on the schedule are at least one week prior to the end of each sprint. While you don’t have to take advantage of the opportunity for feedback, it really is critical to developing high quality software, and that’s the expectation in this course.

Sprint 2 Planning

Looking forward to the next sprint, I’m going to add a couple of explicit requirements:

README
Each project should have a README in their repository that summarizes the project. (You should already have a decent project summary from the W5HH assignment that you can reuse.) You do not need to mention the README in your specification for this sprint, but I expect a pull request that adds it to the root directory of the repository.
Automated testing
All projects must use an automated test framework (e.g., JUnit) to execute unit tests on their code, and by the end of this sprint, the test framework must also be integrated with Travis CI so that each proposed change is checked prior to its acceptance. In most cases, integration with Travis CI is a simple process – essentially a configuration file that specifies the command to execute – but I am certainly willing to help if you have questions, and you can also work collaboratively across teams on this task.

In addition, I will be expecting substantial peer reviews as evidenced by comments on GitHub on all pull requests. Although I am acting as the project maintainer, your teammates should be providing feedback as code is developed, including pointing out places where the design could be improved and cases where the inline comments are insufficient, for example. If I’m not seeing feedback from teammates, then I won’t bother reviewing the pull request – I’ll just post a comment asking them to review it first. Don’t forget to request a pull request review from me after your team agrees that the pull request is ready (i.e., as good as you can make it).

Regarding comments on pull requests, please be sure to mark those that have been addressed as “resolved” so that others (including me!) know that they’ve been dealt with. That makes reviewing easier.

Finally, remember the concept of the minimum viable product as you plan this sprint: start with the smallest kernel of functionality (e.g., a data structure) and build incrementally on it. There’s no limit on the number of pull requests that you can open, and it’s much better to have 4 of 5 pull requests accepted by the end of the sprint than to have one large pull request that still has issues that must be resolved.