In addition to my Python series, I’m writing a series of articles on being a digital scholarship project manager. Miriam Posner has already written some amazing pieces on getting started with the Georgia Lynching Project. As she headed to UCLA, the task of managing the GLP fell to me. I met with the developers yesterday, who were beginning to think about how data would be visualized to users. I quickly learned that I needed to rethink how I imagined digital collaboration and interface design.
First, an aside about project management in institutions like libraries and Universities. Project managers, developers, user-interface designers, copyright experts, researchers, and faculty all work together – along with multiple levels of University administration – to create a digital project. This means that, in all likelihood, what appears on the screen is due to a long process combining ideas, deliberation, and compromise. Matthew Kirschenbaum has argued that what is often taken as the object of critique when considering media objects (the interface), comprises only part – and a small part at that – of a digital work. Even the interface, though, is a product of the complex interactions of collaboration. Politics, psychology, history, and sociology all play a part of collaboration, but it is important to understand that the product that emerges in a digital humanities project is often a strange conglomeration of the intentions of each member and elements that cannot be predicted at the outset. I like what China Mieville says about collaboration. He’s talking about collaborating on comics, but I think the lesson is relevant to digital scholarship as well. When speaking about having his work illustrated by another person, he says “you have to approach it with an open and collaborative frame of mind, because you aren’t creating these characters alone, you’re creating them with someone else, and the thing you create is always a strange combination of your ideas, theirs, and the ineffably generated third element that is sourced from neither of you, but becomes indispensable.”
Digital collaboration at DiSC adds even more layers of complexity, when you combine your intentions, the interests of the faculty member sponsoring the project, the requirements of the grant, copyright concerns, the creativity of your fellow project members, and ultimately the audience you are envisioning for your project. Discussing an interface on a page of The William Blake Archive, Kirschenbaum recalls the meetings and discussions that lead to the development of that page, and the problems of instituting changes. “Most digital humanities scholarship,” he points out, “is produced incrementally, in layers; at least for large-scale projects like the WBA, housed within particular institutional ecosystems, those layers tend to be more sedentary than we like to admit.” One thing I’ve learned as a grant-funded Fellow at DiSC, is that my own creativity is often enveloped in layers of networks that support, limit, and nurture it.
I’ve decided that, in order to become more active in developing the Georgia Lynching Project, I should learn how to craft effective user stories for the developers. User stories are sets of instructions that specifically lay out what the project manager wants a user to be able to do in a given project. Here’s a screenshot of our user stories for the most recent milestone and the user stories and tasks associated with that milestone. User stories and milestones for Emory projects are housed on the “Track Sites” portion of EUL Tech-Know-How, developed by Emory Libraries to help software engineers better communicate with one another. The track site for the Georgia Lynching Project shows how far along developers are with any given task for the many projects they work on. One admission: Sari Connard wrote the following user stories and tasks. She’s also helping me learn the ins and outs of user stories, for which I owe her a huge thanks.
Crafting a user story seems simple enough. But it is important to remember Kirschenbaum’s point that digital projects are released incrementally. This means that the site’s features need to be prioritized. Mike Cohn discusses priority in User Stories Applied: For Agile Software Development.
Stories cannot be prioritized without considering their costs. My priority for a vacation spot last summer was Tahiti until I considered its cost. At that point other locations moved up in priority. The cost of the story is the estimate given to it by the developers. Each story is assigned an estimate in story points, which indicates the size and complexity of the story relative to other stories. So, a story estimated at four story points is expected to take twice as long as a story estimated at two story points. (11)
After assigning points to each story, the developers break up the stories into individual tasks. You’ll see from the example above, that there are two stories but the first story requires nine tasks while the second story only requires two tasks. Once tasks and stories are completed, the project manager receives a list of features to test and sign off.
What are the features of good user stories? Obviously, different teams work differently and different developers like different things when reading user stories. However, there are several features that are important across the board. I’ll quote from Andrew Stellman’s blog:
- User stories are about needs. When you write a user story, what you’re describing is a “raw” user need. It’s something that the user needs to do in his day-to-day job. If y0u never build any software for him, then that need will still exist! [...]
- User stories are easy for users to read. When you write a user story, what you’re concentrating on is writing something that anyone can understand, in the language of the users. We all know that developers have a lot more patience for talking about details of the software they’re building than users do, which is why user stories have to be brief. A user story needs to express a complete thought in just a couple of sentences. (That’s also why it’s good to put them on index cards: somehow, that makes it clearer that it’s self-contained and independent of the other user stories.)
User stories need to think specifically about the user. This means that project teams need to think seriously about the intended audience of their project. Do you feel, for instance, that only scholars will be interested in the digital project? If you’d like to have a public audience, then you’ll need to have a pretty radically different site and interface than if you only wanted scholars to access data. Further, user stories need to be clear, concise, and easy to understand. Remember that you are basically writing a set of instructions to be interpreted by developers and users themselves. If users do not know what a JSON query is, then it’s likely that they won’t be able to test any story that includes that phrase. When writing user stories, it is (therefore) important to remember not only the users but also the developers as audiences. Better, clearer, and more concise user stories make better digital projects.
The most interesting part of learning about project management is researching its roots in business culture. Project managers are called by different people as “project owners” or simply “the customer.” These names reinforce the problematic, for me, idea that developers are simply providing a service, while project managers are the ones who ultimately own the project. I wonder if another model wouldn’t be more effective in emphasizing a model of authorship that is more collaborative. For now, though, the process has been remarkably enlightening and has given me insight into how large-scale production actually gets done.