Deliverable

This is the final sprint. Your goal is to scale your prototype to production data, generate scientifically meaningful results, and deliver a repository that a future researcher could pick up and use without contacting you.

At the start of this sprint, create a branch named deliverable from main. This branch is your sprint’s integration branch. All work for this sprint lives here or in branches that merge into it.

Caution

Your branch must be called deliverable. Not deliverable-final. Not sprint-003. Not anything else.

Do not work directly on deliverable. For each task or feature, create a short-lived branch off of deliverable, do your work there, and open a Pull Request back into deliverable when the work is ready. Name these branches descriptively (e.g., deliverable/slurm-array, deliverable/clustering-analysis, deliverable/readme-methods).

When your team has met the Deliverable Sprint objectives, stop adding new features. Open a Pull Request on GitHub to merge deliverable into main, and explicitly request a review from your entire team and the @dri-26s account.

I will review your submission directly within the PR, adding comments on your codebase and documentation. When I request changes, you must implement them and push the updates back to the deliverable branch. Re-request my review only once all requested changes are complete. We will repeat this process until the work meets production standards and is approved for merging.

Once the PR is merged into main, I will generate a formal Artifact by creating a GitHub Release using calendar versioning (e.g., v26.4.18). This tagged release is the immutable snapshot of your work. Your final grade will be based strictly on the state of the repository as captured in this release. If a fix or a piece of documentation exists in your main branch but was not included before the tag was created, it does not exist for the purposes of evaluation.

Tip

Check your project specification to see what deliverables are expected to be completed in this sprint.

Commit Hygiene

The same commit standards from the Prototype Sprint apply here, and they matter even more at production scale.

Commit early and commit often

A commit should represent a single logical change: one function added, one bug fix attempted, one parameter adjusted. Do not accumulate an afternoon of work into a single commit. If you tried something and it did not work, commit it anyway with a message that says so. That failed attempt is exactly the kind of evidence your sprint report needs.

Write specific commit messages.

Your messages must follow the Conventional Commits specification. The format is:

<type>(<scope>): <description>

Where type is one of feat, fix, docs, refactor, test, chore, or similar; scope is the module or area of the codebase affected; and description is a concise, imperative-mood summary of what changed and why.

Examples of good commit messages:

fix(docking): increase exhaustiveness from 8 to 32 to reduce pose variance
feat(filtering): add PAINS filter using RDKit FilterCatalog
docs(readme): add installation instructions for Pixi environment
fix(prepare): handle missing stereocenter in SMILES parsing (did not resolve #12)

Examples of bad commit messages:

update code
fix stuff
WIP
asdfasdf
final version?

Do not squash commits when merging Pull Requests

When you merge a PR on GitHub, select “Create a merge commit”, not “Squash and merge.” Squashing compresses your entire branch history into a single commit, which destroys the chronological record of your work. I need to see the individual steps, including the wrong turns.

Caution

If your deliverable PR is squash-merged, I will ask you to revert it and re-merge with the full history intact. Protect your evidence.

Sprint Report Template

You will create a file named reports/sprint-03.md in your repository. At the end of every sprint, your team must commit a Sprint Report by 5:00 PM on Friday. Copy the following Markdown content into that file and fill in the bracketed sections. Delete these instructions before submission.

# Sprint 03: Deliverable Report

**Team:** [Insert Team Name]
<br>
**Date:** [Insert Date]
<br>
**Authors:** [Insert Name(s) of Person Writing the Report]

## Scientific Status

_[Re-contextualize the biological problem one final time.
This section should be written as though the reader has never seen your previous reports.
State the problem, the target, the approach, and the specific question your pipeline answers.
This section should read like the opening paragraph of a research paper.]_

## Sprint Outcomes

[Explicitly state whether the goals of the Deliverable Sprint were met, partially met, or missed entirely.
This sprint required you to scale to production data, handle failures, and produce final results.
Culminate this section in a single, decisive sentence summarizing your key scientific finding or the current state of your pipeline's output.]

### Definition of Done

[Evidence is required here in the form of links to files, data, and notes that instantly open if I click on the link.
If it is not linked, it does not exist.]

## Technical Struggle Documentation

This section is the most heavily weighted component of the sprint report.
You are required to document exactly two significant technical problems your team encountered and fought through during this sprint.
These must be real problems that cost your team real time.
Do not fabricate or exaggerate a struggle.
I will verify every claim against your commit history.

For each of the two problems, you must provide the following in this exact order.

### Struggle 1: [Descriptive Title]

#### What we were trying to do

[State the specific technical task you were working on when the problem surfaced.
Link to the commit or branch where this work was happening.
Example: "We were writing the ligand preparation function in `src/prepare_ligands.py` ([permalink to file at that commit])"]

#### What went wrong

[Describe the failure precisely.
Make sure to paste the exact error message, traceback, or unexpected output in a code block.
If the problem was not an error but a scientific result that did not make sense, show the data or figure that raised the flag.
Do not summarize; show the raw evidence.]

#### Why we thought our original approach would work

[Explain the reasoning that led you to the approach that failed.
What documentation did you read?
What example did you follow?
What assumption did you make?
This section demonstrates that you were thinking before you coded, not just guessing.]

#### Everything we tried, in order

[This is the core of the section.
Walk through every attempt you made to fix the problem chronologically.
Each attempt must include:]

**Attempt 1**

[Explain what you tried, and be specific.
Link to the exact commit where this attempt is visible. Use [GitHub permalinks](https://docs.github.com/en/repositories/working-with-files/using-files/getting-permanent-links-to-files) (i.e., links pinned to a specific commit SHA, not to `main` or `dev`).
If you changed a parameter, state the old value and the new value.
If you restructured code, describe what you moved and why.]

[Explain why you thought this would help. What was your hypothesis for why this change would resolve the problem?
Did you find a Stack Overflow answer, a passage in the tool's documentation, or a section of a paper that suggested this fix?
Link to it.]

[Describe what happened. Paste the new output, error, or result. Did the problem change? Get worse? Partially resolve?]

**Attempt 2**

[Repeat this numbered sequence for every attempt.
Two attempts is a minimum; I expect most real problems to involve three to six iterations.
If you solved it in one try, it was not a significant struggle.]

#### Resolution

[State what ultimately worked and link to the commit where the fix is merged.
If the problem is not yet resolved, say so explicitly.
Describe your current best hypothesis for the root cause and your plan for the next sprint.
Unresolved problems documented with rigor earn full marks.
Unresolved problems with vague documentation do not.]

#### What we learned

[One to three sentences.
What does your team now understand that you did not understand before this problem?
How will this knowledge change how you approach similar tasks in the next sprint?]

### Struggle 2: [Descriptive Title]

[Repeat the same structure as Struggle 1.]

## Reflection

[This section replaces the Planning section from previous sprints.
There is no next sprint.
Instead, reflect on the project as a whole.]

### What would you do differently?

[If you were starting this project over with the knowledge you have now, what would you change about your approach, your architecture, or your team workflow?]

### What remains incomplete?

[Be honest about the limitations of your deliverable.
What would the next sprint look like if there were one?
What open questions does your work raise?]

### What are you most proud of?

[Identify the single technical or scientific achievement from this semester that your team considers its best work.
Link to the evidence.]

Rubric

The sprint report is worth 25 points distributed as follows.

Section	Points	What earns full marks	What does not
Scientific Status	1	Clear, self-contained re-contextualization of the biological problem. A reader encountering your project for the first time can understand the target, the approach, and the question your pipeline answers. Written at the quality of an opening paragraph in a research paper.	Copy-pasted from a previous report. Missing explanation of the specific question your pipeline addresses. Assumes the reader has prior context.
Sprint Reporting	2	Honest, specific assessment of what was achieved at production scale. If goals were partially met or missed entirely, this is stated directly with an explanation of why. The reporting accurately reflects the state of the repository. The summary sentence is a concrete scientific or technical claim, not a process update.	Vague language like “we ran the full pipeline.” Overstating results relative to the evidence in the repository. A summary sentence that describes activity rather than outcome.
Sprint Completion	3	The deliverable sprint objectives from your project specification are met. The “Definition of Done” section contains permalinks to production scripts, output data, and embedded figures generated by the pipeline. The pipeline runs reproducibly from the repository.	Objectives are partially met with no explanation of what remains or why. Missing or broken links. Figures that are screenshots rather than programmatically generated outputs. The pipeline does not run from the repository without manual intervention.
Struggle 1	7	All six subsections are present and substantive. Every claim is backed by a permalink to the relevant commit. The “Everything we tried” section contains at least three chronological attempts, each with a hypothesis, an action, and a result. The reasoning is genuine and specific to your problem, not generic.	Fewer than three attempts documented. Missing permalinks. Descriptions that read like a tutorial rather than a narrative of real debugging. Evidence that the “struggle” was trivially solvable.
Struggle 2	7	Same criteria as Struggle 1. The two struggles must be meaningfully different problems, not two symptoms of the same root cause.	Same root cause as Struggle 1 repackaged. Substantially less detail than Struggle 1.
Reflection	3	All three subsections are present and substantive. The “what would you do differently” section demonstrates genuine hindsight, not generic platitudes. Limitations are stated honestly. The “most proud of” section links to specific evidence in the repository.	Generic reflections that could apply to any project. Missing or empty subsections. No links to evidence. Dishonest framing of limitations (e.g., “we wouldn’t change anything”).
Writing quality	2	Professional, concise scientific English. Markdown is well-formatted. The report could be handed to the project sponsor without embarrassment. Figures are captioned and referenced in the text.	Sloppy formatting, grammatical errors that impede comprehension, or an unprofessional tone. Figures dumped into the report without context.

A note on what “struggle” means

The same standard from the Prototype Sprint applies here.

I am not grading the difficulty of the problem. I am not grading whether you solved it. I am grading the depth and honesty of your engagement with the problem.

A team that documents a week-long fight with SLURM job array failures at scale and ultimately does not fully resolve it will earn more points than a team that presents a neatly resolved problem with no evidence of the messy middle.

At production scale, the problems you encounter will be harder, stranger, and less googleable than what you hit during the prototype. That is expected. Document the reality of what happened, not a sanitized version of it.

A note on the Reflection section

This is the only time in the course I ask you to look backward. I am not looking for gratitude or sentiment. I am looking for evidence that you can critically evaluate your own work.

The ability to identify what you would change, what remains incomplete, and what succeeded is a skill that distinguishes junior engineers from senior ones. It is also exactly what I will be listening for during the final code review.

The README

Your README.md is your final paper. It is graded as part of the deliverable component of your course grade (separate from the sprint report). Refer to the syllabus and your project specification for the full requirements.

The sprint report documents your process. The README documents your product. They are complementary, not redundant. Do not copy sections between them.

Last updated on March 8, 2026