2025 ASEE Annual Conference & Exposition

Scrum is a project management technique developed for software engineering that has shown great ability in maintaining project flexibility, quality, and customer satisfaction. It has been primarily used in industry, where team members have few projects, projects are uni-disciplinary, and team members often have similar areas of expertise. The X Department at X University has recently implemented Scrum in its faculty service committees. The scope and application of projects in the faculty service setting varies from the traditional industry setting. This work aims to determine what aspects of a project make it suitable to be managed by a Scrum framework. In annual faculty interviews and recorded Scrum meetings over three years, there were many discussions about the projects best suited to Scrum. In total, ten projects were analyzed over three years. This paper analyzes the recorded interactions to determine the projects best suited for Scrum and their characteristics so that this work can serve as guidance for adapting projects to Scrum in a wide variety of domains.

This research determined that inherently iterative projects are well suited to Scrum because of Scrum’s flexibility to adapt to changing requirements. Therefore, as requirements changed, the Scrum Team (i.e., the “committee”) was able to adjust its goals and tasks to meet those needs. It was found that complex, multi-disciplinary projects are also well suited to Scrum because the project tasks are easily split among team members based on areas of expertise. More complex projects have more tasks, and teams benefit from breaking the goals into smaller tasks to fit within a sprint. Additionally, with more complex projects, the overhead of adapting to Scrum was balanced by the increased efficiency brought about by using the Scrum framework. However, Scrum did not benefit certain projects. Scrum teams that did not find Scrum effective had tasks that were not easily divisible or lacked a clear goal to work towards. When a Scrum team’s tasks were often small and took little time, it felt as though the Scrum overhead took more time than the tasks themselves, making Scrum frustrating to follow.