Doing digital scholarship: Creating and refining a feature list

by Miriam Posner, Mellon Postdoctoral Fellow, Digital Scholarship Commons

From time to time, I'll be blogging on behalf of the Digital Scholarship Commons about our work to build the Georgia Lynching Project, which documents the history of lynching in Georgia. Read our other installments here!

When I last wrote about the Georgia Lynching Project, I described our work to hammer out a project charter — the document that lays out the ground rules for our interactions over the course of the project.

Once our charter was in place, we were all set to start discussing the project itself. There are a lot of ways to start planning a digital project. Over the course of our next several meetings, we used a modified decision matrix: a semi-magical tool that helped us figure out how to prioritize our ideas.

In the first step, we gathered as a team and shouted out our ideas for what our project should do. It was just a brainstorm, so there were no limits at this point. "Let's have word clouds!" we said. "How about timesliders?" "Charts and graphs!"

We ended up with a pretty long list: 21 features, some do-able, some not-so-do-able.

In the interval between this meeting and the next, Scott Turnbull, the fearless and awesome manager of our development team, grouped these features and translated them into developer-speak.

Here's what Scott's feature list looked like:

1. Internal data joined via RDF relationships and a SPARQL-like GUI builder for basic queries.
2. Ability to pull in data from other SPARQL endpoints; that is, we’re a consumer of RDF, but not (yet) a provider.
3. The ability to manage scanned primary sources within the application. The app should manage access to these items.
4. Session-based notification and opt-in permission to view files (i.e., “These documents might be sensitive. Do you want to view them?”)
5. Visualize data as geographic map overlays
6. Visualize data as relationship maps
7. Full-text search on OCR

This list may look a bit confusing, but here's what it means. We want to be able to (1) allow users to query our database; (2) pull in data from other sources, (3) deliver scanned newspaper articles to users, depending on the articles' copyright status; (4) ask the user to verify that he or she wants to see potentially upsetting information; (5) view the data on a map; (6) view maps of relationships; and (6) perform a full-text search of our newspaper articles.

Now that we had this list, we ranked the items in terms of priority. We decided that the most important features to us are, in order of importance, numbers 1, 3, 7, 6, 5, 2, and 6.

Now for the magical part! Scott drew a grid on the board and the developers, Sari Connard and Ben Ranker, gave rough estimates of these items' difficulty to build. This is the grid that emerged:

We liked the way this grid looked, because nothing's in the lower-righthand corner. That is, nothing is high difficulty and low importance. Item number one, the most difficult, is also the most important. That's good!

So it looks like we have a do-able project. In the next step, Scott, Sari, and Ben will translate our features into "user stories," which will allow Scott to make detailed estimates of our timeline. More soon!