I was recently asked a question about applying Scrum to research projects. The core issue had to do with Scrum’s fixed time boxes. Research projects, by their very nature, aren’t driven by fixed deadlines. Depending upon the complexity of the research, the effort could take weeks, months or years. How do you apply Scrum?
While Kanban may actually be a better fit simply due to it’s flexible timing, I’m going to focus on Scrum because it was the context of the question.
Research is often a systematic investigation designed to harvest knowledge from facts and observations. Research projects frequently deal with fluctuating requirements that result from new knowledge learned via scientific inquiry. As new findings emerge, new interpretations of the original goals evolve and the process may have to begin anew.
Here are a few key areas where research projects differ from product development projects.
- The requirements may be broader and more loosely defined.
- Stories (or use cases) may be harder to estimate regardless of the measure used for units of work.
- The work plan may require more flexibility and on-the-fly planning.
- The project goals may be moving targets.
- Substantial documentation may be required.
Despite these challenges, Scrum can work. Just like product development, research is a structured and disciplined effort. Even if the research is largely based on observation, the results being observed will lead to the definition of new stories that will get added to the backlog like any Scrum project. We may need to bend Scrum rules a bit, but that’s okay. The basic Scrum principles will still work.
Scrum Guidelines for Research Projects
Here are a few guidelines for conducting research using Scrum as the process that drives the team.
- Keep Sprints short. Shorter sprints will make it easier to adjust to new information and changing “requirements”. Consider 1-2 week Sprints.
- Keep stories small. For example, setting up an experiment, doing it, and documenting the results can be separate stories. Think about activities that can be completed in 1-2 days.
- Each Sprint does not have to “deliver” something tangible as in product development. An observation made during a Sprint may be immensely valuable though not yet documented or even analyzed.
- Don’t be afraid to abort a Sprint. If something unexpected is discovered and the Sprint backlog is severely impacted, end the Sprint and regroup. (Just don’t make a habit of it.)
- The Research Owner (there is no Product Owner) and the end user may be the same person during the project. Only when the research is complete will the results be made available to outsiders.
Finally, daily standups, a Scrum Master who removes impediments, and good backlog management apply to any project using Scrum. Give it a try on your next research project.