Sprints
Research is rarely a straight line from hypothesis to discovery. It is a cycle of trial, error, debugging, and refinement. To mirror the workflow of professional research software engineers and agile labs, this course replaces the traditional “Midterm Exam” with Sprint Cycles.
A sprint is a focused period where your team attempts to achieve a specific set of technical and scientific goals. At the end of each sprint, you do not just “turn in homework”; you deliver a working product increment and a Sprint Report.
Schedule
We will be follow the tentative sprint schedule shown below.
| Sprint | Week(s) | Theme | Goal |
|---|---|---|---|
| 1 | 4 | Charter | Form teams. Set up the GitHub repo structure. Write the “Team Charter”. |
| 2 | 5 – 8 | Prototype | Build the pipeline and run it on a toy dataset. |
| Spring Break | |||
| 3 | 9 – 11 | Production | Run the full pipeline on the real dataset. Handle errors and scaling issues. |
| 4 | 12 – 14 | Deliverable | Analyze the results and visualize findings. |
Report
At the end of every sprint, your team must commit a Sprint Report by 5:00 PM on Friday.
This is not a casual reflection paper or a loose collection of notes; it is a formal technical document that serves as the primary record of your scientific and engineering progress.
You must author this report in Markdown (.md) format and push it to a dedicated reports/ directory within your team’s GitHub repository (e.g., reports/sprint-01.md).
Contents
The report should be concise yet dense with information, aiming for approximately 500 – 1,000 words. It must be written with professional clarity, suitable for review by a Principal Investigator or a Product Manager.
Objectives
The report must open with a scientific status section that serves as an executive summary for external readers. You cannot assume the reader remembers exactly what you planned three weeks ago, so you must briefly re-contextualize the sprint’s original objectives.
Outcomes
Following this context, you must explicitly state the outcome of the sprint: were the goals met, partially met, or missed entirely? This section must culminate in a single, decisive sentence that summarizes the sprint’s key biological or technical finding. For example, rather than saying “We ran some docking,” you should state, “We successfully docked the 1,000-compound library against SARS-CoV-2 Mpro and identified three ligands with predicted affinities lower than -9.0 kcal/mol.”
The core of your report is the definition of done, where you provide verifiable evidence of your work. In a computational setting, if code or data is not visible in the repository, it effectively does not exist. Therefore, you must avoid vague statements like “we wrote the code” and instead provide direct hyperlinks to the specific Pull Requests, merged commits, or source files in your repository that prove the work was completed. You must also point the reader to the exact directory where generated data files, logs, or analysis outputs are stored. Furthermore, computational biology is an inherently visual field; you are required to embed key figures, such as histograms of docking scores, loss curves for machine learning models, or protein structures, directly into the Markdown file to demonstrate your results visually.
Blockers
Research is unpredictable, and negative data can be a valuable scientific result when analyzed correctly. The blockers and challenges section is your opportunity to document what went wrong and, more importantly, why. You must distinguish between technical failures and scientific failures. If you encountered technical errors, you must paste relevant snippets of stack traces or error logs in collapsible code blocks and describe the debugging steps you attempted. If you encounter a scientific dead end, you must offer a rigorous hypothesis to explain the anomaly. You will receive full credit for a “failed” sprint if this section demonstrates a rigorous, evidence-based analysis of the failure that informs your future direction.
Next Steps
The report must conclude with a next steps section that bridges the current work to the future. You must define the specific technical and scientific goals for the upcoming sprint. Crucially, this section must reflect on the sprint’s results. If your experiments succeeded, what is the logical next step in the pipeline? If they failed, how will you pivot? For instance, if your docking software proved too slow for the dataset, this section should explicitly state the plan to switch to a different algorithm or reduce the library size for the next cycle.