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.
Leave a comment
- June 2013 (8)
- May 2013 (13)
- April 2013 (13)
- March 2013 (13)
- February 2013 (12)
- January 2013 (12)
- December 2012 (7)
- November 2012 (11)
- October 2012 (12)
- September 2012 (8)
- August 2012 (11)
- July 2012 (13)
- June 2012 (12)
- May 2012 (13)
- April 2012 (13)
- March 2012 (13)
- February 2012 (12)
- January 2012 (13)
- December 2011 (12)
- November 2011 (12)
- October 2011 (13)
- September 2011 (14)
- August 2011 (18)
- July 2011 (13)
- June 2011 (18)
- May 2011 (19)
- April 2011 (16)
- March 2011 (21)
- February 2011 (20)
- January 2011 (22)
- December 2010 (21)
- November 2010 (16)
- July 2010 (2)