Background
Back in summer 2025, Research Software Engineers Bianca Matischen and Sarah Jaffa worked with Ramiro Bravo, (Research Data Manager, Faculty of Biology, Medicine and Health), and the Center for Open Science (COS) based in the US. The goal was to develop a utility tool for researchers to download and backup their research uploaded to the Open Science Framework (OSF), a management tool designed to support and enable collaboration on Open Research projects.
As part of that project, they used Agile to manage the project and workload needed for the tool's requirements. In this article we’ll give a run-through of how we used Agile principles and how it helped with the project.
Application of Agile Techniques
Project Kick-off
We started the project with a kick-off meeting with project stakeholders, Ramiro and the COS team, to agree initial requirements for the project and plan where to begin the project development.
Afterwards we began creation of the backup tool using the Scrum framework adapted for research software engineering. In this process we have a Scrum master (Sarah) who acts as a facilitator to ensure development adheres to best practices and helps plan and prioritise work needed to be done from the backlog with the developers (i.e. Bianca) building the software tool and implementing the requirements.
Kicking off development, we created a project board and converted the project requirements into more manageable chunks of work such as features, more general tasks and bug fixes, and added them to the Project Backlog. Features were created using a user story format to explain what it would do, who would use it and how it would benefit. Using this format helps clarify the intended effect of a new feature for a user, so that it can be designed and implemented properly with this in mind.
Sprint Planning and Retrospectives
After deriving issues from the requirements, we started allocating them to timeboxed periods of development called sprints. Each sprint had an overall goal we would like to achieve and covered one week of development, which helped us focus and complete work at a consistent pace within the limited time available.
At the end of each sprint, we would have weekly meetings with all project stakeholders to get their feedback regularly to improve the project’s development. Here we gave a review on the sprint that ended, explaining what was completed and what was blocking progress.
As we were reliant on the OSF API to extract data, it was important we relayed any questions or problems we had with using the API to the COS team so that they could share knowledge or make bug fixes. We then created a plan for the next sprint by adding relevant issues to the project backlog and agreeing which issues to work on in the next sprint.
To help choose issues we also used the MoSCoW framework. This categorises issues into Must Have, Should Have, Could Have and Won’t Do. Issues required to be completed to progress the Sprint goal can be marked as Must Have and done first, with other issues completed in priority order if time allows. Whilst reviewing sprints we could ask stakeholders on whether requirements should be re-prioritised due to time constraints or emergence of new tasks and requirements.
Project Feedback
Over 12 sprints covering over 2 months of work, the backup tool was developed and released as a Python library called osfexport, allowing OSF users to use the CLI (Command Line Interface) or a web version to export their projects to PDF format. The final sprint focused on handing over the codebase to the COS team. The COS team were delighted with how the process enabled conversations and feedback on the tool’s development, and used our project board as an example of good project management to other open-source project groups.
Huge Shout-out to the University of Manchester team! We have been using their GitHub project management board for their weekly scrums. It has streamlined our conversations, and it looks FANTASTIC! You don't need to follow this format exactly, but I just wanted to highlight how awesome these things can look!
More Information
Check out The Great Scrum Switch Over and Agile Methods for RSEs to learn more about the methods we use and our journey in switching over to using Agile. We also reflected on how to use Agile methods outside of software development in Learning from User-Centric Design, Systems Thinking, and Agile Practice.
If you’re considering RSE support on one of your projects, please review our Terms of Engagement and get in touch to arrange an initial meeting via our Connect form.