by Mike Casey, Director of Technical Operations, Media Digitization and Preservation Initiative, Indiana University
This is a continuation of a post discussing the use of scrum procedures to help manage a media digitization operation. In part 1 we explored how scrum influences time, choice, and morale. In part 2 we begin with ideas related to a philosophy of continual improvement.
In addition to the biweekly sprint meeting, IUMDS staff gather first thing each morning for the daily scrum or standup meeting. This meeting lasts from five to fifteen minutes and includes all staff, not just those engaged in digitization. Sometimes we take the classic scrum approach and everyone takes turns briefly stating what they worked on yesterday, what they will work on today, and whether they see any issues or problems. Often, it’s more like a rugby scrum where anyone, in any order, brings up issues or updates for the group to consider. We are careful to move discussions that will take longer than a few minutes or will dive into the technical weeds of a problem to a smaller breakout meeting either immediately following the standup or at some later time.
The daily standups along with the biweekly sprint meetings provide built-in frequent feedback loops for both technical staff and administration. Any given staff member is typically just a day or weekend away from soliciting and receiving guidance on an issue. Administrators always know where things stand and don’t have to drop in on staff in the middle of the day in order to learn what they are working on. In addition, these meetings enable us to change directions or tweak something quickly, providing flexibility to the operation.
IUMDS uses a software application called Jira to maintain and track the backlog of recordings to be digitized. Jira is widely used by software development teams that follow an Agile process. Incoming recordings are divided into groups or batches based on technical characteristics so that digitization engineers may realize efficiencies from working on like items. In software development, items added to the backlog are written in a story format and the development team assigns points to each story representing how much coding work they believe it will take to complete each story. This provides a measure of the productivity of the team for any given sprint or sprints. More points equals more work done.
Our situation is a bit different. Productivity in a media digitization workflow is measured largely by the number of hours of source recordings that are successfully digitized during a sprint. Therefore, we calculate the playback time of each batch and use this number for story points in Jira. So far, this is working more effectively for audio than for video as the prep process for audio recordings in our workflow more readily lends itself to estimating duration. For video we are currently using the less accurate measure of the number of tapes digitized. Note that a full set of statistics that includes video durations is collected as part of a separate process that runs post-digitization.
In our experience, adopting scrum has enhanced team communication as well as provided flexibility to quickly adapt to emerging realities. It positively affects investment, engagement, and productivity. In rugby terms, that’s as good as a try!
 Stories provide a high-level description of a feature identifying who, what, and why. Scrum stories typically use the following template:
As a [role]
I want [goal]
So that [benefit]
 In rugby, a try is a way of scoring points where the ball must be in contact with the ground in the opposition’s goal area as well as touching the attacking player.