Book sprinting with SPRUCE
We are now into the final few months of the SPRUCE Project and we're beginning to complete some key outputs from the project. A key aim has been to encourage and support digital preservation activity in the UK from both a technical and business perspective. So we wanted to support practitioners in bringing in the funding they need to make preservation happen. To that end, we've produced a toolkit that guides them through the process of writing a business case focused on digital preservation:
We then began to fill out how each of our chapter headings would look. We started with high level bullet points, created by small teams who would focus on a section for a short amount of time. We'd then do a switch around and get the groups to review each others work. Crucial sections had reviews completed by all of our 13 sprinters, ensuring that the really important parts of the guide had some really thorough input from all of our experts. By this stage I was feeling much happier about where the sprint was heading and the content that the sprinters were churning out was starting to look very good.
A challenge we hadn't encountered while running our mashup events, at least in quite the same way, was participant fatigue. Our mashups have an almost narrative-like structure. With an event progressing reasonably fluidly throughout the 3 days, we work the mashers hard and they get tired, but there hasn't been a need to keep them motivated (bless em!). With the book sprint, it was a little different. Hacking out words rather than code is quite different. Writers aren't always used to tapping the keyboard into the small hours, with only the briefest (if frequent) thoughts of pizza and/or caffeine. Speaking personally, sometimes I can sit down at a keyboard and churn out a blog post or report. Other times I can't get past the first sentence. On top of changing "writing moods" we were also tackling some tricky business case problems. Real "think til your head hurts" kind of problems….



Last year I