➤Accepted sprints |
➤Sprint reports |
➤Lessons learned |
|---|
The sprint process: from sprint check to report
natESM maintains an open call for proposals, enabling model-development groups across Germany to become part of our Earth-system research community.
Our sprints, focused on technical objectives and tethered to natESM resources, provide a flexible program tailored to your research goals and timelines. This collaborative journey spans up to six months, fostering in-depth partnerships between you and our Research Software Engineers (RSEs).
The sprint process within natESM encompasses several stages, ensuring that each sprint effectively contributes to our Earth system modeling objectives. Here is an overview of the sprint journey that you can initiate at any time. Prospective applicants are required to undergo a sprint check, serving as an accessible entry point for guidance before submitting a full sprint application.
1. Sprint check - from idea to clarity
The Sprint Check is your low-threshold entry point into the natESM sprint process. It is designed for scientists who have a model, a piece of code, or a technical challenge they would like to improve or better integrate into natESM – even if they have little experience with software engineering or collaborative development.
The Sprint Check is not a review and not a mini-sprint. It’s a short, guided preparation phase that helps you and the RSE team understand whether your idea is technically feasible and what would still be needed for a full sprint proposal.
How to get started
To help the RSEs prepare, please include a few short pieces of information in your initial e-mail to c3VwcG9ydC1yZXF1ZXN0QG5hdC1lc20uZGU=. You don’t need to fill in a form — just answer these questions briefly in your message:
| Field | Purpose | |
| Title of your idea | Just a short working title. | |
| Main challenge / bottleneck | What’s not working or what you’d like to improve.
|
|
| What exists already | Briefly describe your current code, setup, or test case. | |
| Code access | Provide a link to your Git repository (public or shared), or describe how the RSEs can access the relevant parts of your code. | |
| What you imagine a sprint could achieve | (Optional) A short vision — one sentence is enough. | |
| Who else should be involved | (Optional) Names of colleagues or model components. |
That's all you need to start; a short email with this information is enough.
The RSEs will review it briefly and contact you to schedule the first discussion.
What happens during the sprint check
-
Preparation by the RSEs
The RSEs briefly review the material you sent to understand the context and identify potential technical entry points. -
Initial meeting (30–45 minutes)
You introduce your idea and current setup.
Together, you discuss what could be explored or clarified to make the idea technically ready for a sprint. -
Short exploration (up to 2 weeks)
The RSEs check basic feasibility:
– Can the code be accessed and built?
– Is there a working example or minimal test case?
– Are there technical dependencies that may require preparation?
The goal is to identify what is technically achievable within a sprint timeframe, not to develop or test solutions yet.
The goal is to ensure that each future sprint starts from a focused, working setup or test case.
Feedback and outcome
You receive a short summary describing:
- whether the idea is technically feasible for a sprint,
- what limitations or risks exist, and
- what preparatory steps would make the proposal stronger.
The feedback will indicate one of three outcomes: 1 - Ready for sprint proposal, 2 - Needs some preparation before proceeding, or 3 - Not feasible at this stage.
After the sprint check
If your idea is ready, you can use the feedback from the sprint check to prepare a full sprint proposal on your own. This proposal should clearly describe the sprint goals, expected results, and available resources.
If your idea is not ready yet, you’ll receive advice on what to prepare (for example, improved documentation or a simpler setup) and are welcome to reapply later.
The sprint-check outcome must clearly define which setup or test case will serve as the technical foundation for the sprint. Hence, the sprint check turns an initial idea into a technically sound concept — helping researchers prepare realistic and achievable sprint proposals independently.
Times and roles
- A Sprint Check typically lasts about 2 weeks, with up to one working day of RSE time in total.
- The RSEs’ role is to provide technical guidance and feasibility assessment, not to develop code or assist with proposal writing.
- Applicants are responsible for providing the basic materials, responding quickly, and preparing their full sprint proposal based on the feedback received.
Please note: A successful sprint check with a recommendation to submit a full proposal does not imply that the proposal will be accepted!
2. Sprint application
Researchers submit a comprehensive sprint application (provided after a successful sprint check), considering advice from the sprint check, detailing proposed goals, scope, and expected outcomes to c3VwcG9ydC1yZXF1ZXN0QG5hdC1lc20uZGU=.
The application should also specify who from the proposing team will actively contribute to the code during the sprint, ensuring ongoing collaboration and integration.
3. Expert review
The RSEs, the coordinator, and steering-group members conduct a thorough review of full sprint applications over approximately six weeks.
4. Notification
Applicants are notified of the outcome by email. If accepted, a KickOff meeting is set up to initiate collaboration.
5. KickOff meeting
The official start of the sprint, where the appointed RSE is introduced. This meeting establishes initial goals, communication frameworks, and team dynamics.
6. Weekly meetings
To ensure continuous collaboration, the responsible scientist and the RSE must agree on a fixed weekly meeting schedule during the kickoff meeting or shortly thereafter. These meetings are a mandatory component of the sprint, facilitating regular updates on progress, discussing challenges, and ensuring close cooperation.
These meetings are also the main forum for ensuring that continuous integration (CI) takes place and that developed features are regularly tested and merged.
7. Status meeting
After one-third of the total sprint duration, a status meeting is conducted to evaluate progress and address any challenges. This meeting ensures that the sprint remains on track and aligned with its objectives.
In rare cases, a sprint may need to be discontinued before its planned end. This decision should only be considered if, despite joint efforts and adapted goals, the project proves technically unfeasible or misaligned with natESM’s strategic aims. A possible exit should be discussed transparently between the scientific team, the RSE, and the natESM coordination. The final decision rests with the steering committee.
8. Sprint report
After the sprint, applicants collaborate with RSEs to prepare a detailed report, highlighting achievements, outcomes, and lessons learned. Published on the natESM website within three months, the report provides valuable insights for the natESM community.
All developed code should be merged task by task or, at the latest, by the end of the sprint (task-based merging).
This ensures that no developments remain unintegrated after the sprint concludes.
9. Presentation of sprint outcomes
The responsible scientist (or an authorized representative) is required to present the sprint's outcomes at the yearly community workshop. This fosters transparency, encourages knowledge-sharing, and strengthens collaboration within the natESM community.
10. Follow-up evaluation
Around one year after a sprint, natESM will evaluate its outcomes to assess the long-term impact. The evaluation also considers how effectively the sprint results were integrated into the main code base and whether the collaboration model — including active developer involvement and timely merging — supported sustainable outcomes. The objective is to ensure that the resources invested, including RSE time and funding, have contributed to advancements that benefit the broader community.