So, I’m assuming you’re reading this because you didn’t do very well on Sprint 1. That’s okay, neither did we, that’s why this document was created. If you’re one of those over-achievers reading this on Project Day 1: good for you, tell your class to do the same.

Every sprint is broken up into three parts: the specification, the implementation, and the retrospective. To save time, the biggest thing to know from each one of these is start early, divide the work, and be thoughtful, respectively. If you do those three things across the sprint, it will already go much easier and be less painless for you. But now down to the nitty-gritty.

Picking a Project

The most important part of the project is picking what you want to be working on. Put at least some thought into this, because if you pick a visualization project, and no one on your team has any experience with it, it’s going to be a long semester. Instead pick a project that relates to something y’all are interested in and that you have the ability to code. While you should seek to expand your coding knowledge, don’t pick a project will take your focus away from Comp Sci 350.

Specification

The specification is the first thing you want to tackle, I recommend starting immediately after the project is assigned or you finish last sprint’s retrospective. This means no procrastinating and keeping the problem fresh in your head.

A couple of hints on the specification: only define the problem you are solving in the current sprint; don’t get ahead of yourself. As Qui-Gon Jinn advises, “Keep your concentration here and now, where it belongs.” Second, be specific, don’t vaguely describe the problem and solution. The more work and thought you put in now will mean less confusion and deliberation in the middle of implementation.

Here is a list with everything a specification should have:

Problem Description
Identify what the project is, what it is trying to fix, and broadly how is it going to fix the problem. For each sprint include what the goal of that sprint is.
Requirements
Identify what the sprint must do to accomplish the goal in support of the bigger problem. Include both functional and non-functional requirements.
Use Cases
Describe how the users of the system will use the functionality of the program once the sprint is finished. Do not include functionality from beyond the current sprint.
Proposed Changes
Talk about how the current system is working and how this sprint is going to improve upon that in support of the bigger problem.
Alternatives
Briefly describe how the problem could be solved in other ways and why you chose to approach the sprint in the way you did.
Testing
Identify what, how, and when you will test specific parts of the functionality of the sprint. A good rule of thumb in later sprints is to ensure the program hasn’t broken with your changes – i.e., clean integration.
Documentation
Unlike a documentation statement, this section identifies how you will document your work (e.g., source code comments). I suggest creating a README file and putting the link to that in this section.
Work Item
Break the sprint into smaller sections that can be assigned to group members. The more specific you are here, the more defined the roles within the group will be and the easier it will be to complete the sprint.
Assignee(s)
Document which group members will be working on each of the prior work items. Include the email address of each member.
References
This is most like your documentation statement. Include anything you used to complete the sprint and specification here.

As a reminder, the earlier you start the specification and get it approved, the earlier you can start coding the project. It’s called a specific-ation for a reason, so don’t skimp on the details.

Implementation

So now that you’ve made a killer specification, it’s time to code. Because you’ve already split the work up, this is the easy part. The hard part? Getting the pull request approved. So to help you out here are tips to get done on the first couple of tries, not the 30th.

  1. Create a new branch, named for the change you are going to make (e.g., “add-a-gui”)
  2. Only make changes in that branch related to the change
  3. Do not mix changes in different branches
  4. Turn in something that works (i.e., don’t just code 50 lines and submit)
  5. Limit the code per branch / pull request (<200 is a good idea)
  6. Only include your code (watch out for extraneous files like libraries in your environment)
  7. If the branch is an intermediate, clearly state how this will fit into the larger picture
  8. You will probably have more than one branch and pull request per sprint so keep track
  9. Comment, Comment, Comment #Comment //Comment %Comment /Comment/
  10. Review other members’ code before submitting them for a pull request

As stated before, the earlier you start, the easier it is for your group to fully complete the sprint. This also provides more time for the instructor to provide feedback and make changes.

Retrospective

After a finally getting that pull request approved, all you want to do is not think about the project until the start of the next one, but wait, you’re not actually done yet. Your group has to write a retrospective. The important thing to remember is to actually make the changes you suggest in the retrospective. It does you no good to write “We should have started earlier” and then in the next sprint start the night before again.

Be thoughtful in your responses here, because a good reflection leads to smoother future sprints. I recommend identifying the 3 or 4 biggest problems your group saw and talk about ways to improve so these issues won’t happen again. Like before, be specific so that you are held accountable to your group members if the same mistake is made again.

Parting Words

That’s all a sprint really is, and you get three of them so it helps to do well. Hopefully this document can serve as a guide on your quest to passing Comp Sci 350. If you want a more technical reading just go to the course website where, for the sake of not being redundant, I was attempting not to cover in full detail. Combined, however, these to resources will prove invaluable to your group as you move forward. Best of luck!