Owen Biesel

Part of my job as an academic is to write up and share my research results with the rest of the mathematical community, but while I moderately enjoy writing, I don’t enjoy how long it takes me: I spend a lot of time rewriting whole sections to make a point slightly better, or having to rewrite proofs because I end up needing slightly different definitions. I’ve tried a few different methods for handling the writing process better — I’ve tried Terry Tao’s rapid prototyping method, and I’ve even tried adapting the Snowflake Mathod for writing novels, but I ended up with the same problems: after writing a theorems-only version of the paper I’d need to rework it because my proofs needed different definitions, and my snowflake-esque paper has reached spreadsheet form but I keep reordering the sections based on new insights.

So when I read Jeff Sutherland’s book Scrum about a method for organizing work in teams to minimize the amount of wasted effort and time spent before the team has a workable product, I immediately thought it might be a way past my writing difficulties. At about the same time one of my research projects turned up a paper-worthy result, so I decided to see how quickly I could write it up with Scrum. This blog post is about how that experiment went.

Short version: It was amazing and I’m never going back.

Long version: Here are the key principles of Scrum as I see them, and here’s how I adapted them to my situation.

1. Keep a “backlog” of features to implement, and once a week (or other fixed time interval), decide what to implement next. For me, this meant starting with the main theorems I wanted to prove, and starting by writing their statements and proofs in full. I added any supporting definitions or lemmas to the backlog as I needed them, which kept me focused on writing up the main results. Then the next week, I pulled the next most important layer of results from the backlog and wrote them up, and so on.
2. For each feature, assign it a rough estimate of how much work it will take, and keep track of how much work is being accomplished each week. The suggestion is to give each addition some estimated number of abstract “points”: one to three points for a small job, up to eight or thirteen points for a big job. (Sticking to Fibonacci numbers helps keep from mental haggling over whether something feels like an eight- or a nine-point job.) I also kept track of my writing start and end times during each week, and at the end of each week I totaled how many points of work I’d accomplished and how much time it took.
3. Represent progress visually. I used a Trello board with columns titled “Possibilities to include” (my version of the “backlog”), “This week’s additions”, “Drafting”, and “Done”. At the beginning of the week I’d move cards from “Possibilities to include” to “This week’s additions”, and from there to either “Done” or “Drafting” (if I wasn’t able to finish it during a single writing session). Each card name started with its point estimate of how much work it would take. At the end of the week I’d copy all the “Done” card titles into a spreadsheet that would total up the points for me, and I’d empty the “Done” list. As I wrote, if something occurred to me that I needed to write up but wasn’t one of this week’s chosen additions, I’d add it to the “possibilities to include” list for later.
4. Stop when you’ve reached 80% of the value. This was hard for me, but I deliberately left out some of the “possibilities to include” that I thought would be good changes to make but weren’t necessarily worth the effort. It’s also a less polished paper than I usually write, but I think it’s better that it get out into the world sooner than that I keep it back until it’s perfect.

The idea is to have as soon as possible, ideally at the end of each week-long “sprint”, a version of the product that’s ready to share with the people who will benefit from it. I didn’t always manage this every week, but when the time came to share an early draft with colleagues it was definitely helpful to have the main ideas already written up, rather than a carefully written collection of all the usual definitions and lemmas I thought I might need. Meanwhile, this is also the fastest a project has ever gone from the “main proofs worked out in my notebook” stage to the “posted on the arxiv” stage, so I’m very pleased with this method and I am looking forward to using it on my next project.

In case you’re interested in some statistics:

• I had 28 writing days spread out over sixteen weeks. My total amount of time actually spent writing the paper was 20.3 hours, for an average of about 43.5 minutes of writing time on each day where I did at least some writing, and an average of 76 minutes of writing per week. I’d love to increase both the amount of time I’m dedicating to writing each week, and the amount of time I’m giving myself to write in each sitting.
• I incorporated 38 additions into the paper, with an total point value of 202 points, for an average of 5.3 points per addition. I’d like to keep track of this average for future projects to see if my estimates inflate or deflate over time.
• My “flow rate” on average was almost exactly 10 points per hour. I will keep track of this to see if it changes over time, but if it holds it will be very helpful for planning about how much I can intend to write each week.
• Here is a scatter plot of volume produced each week against the amount of writing time each week. Some weeks have no volume recorded because I was working on high-point-value additions that I wasn’t able to finish until the next week, and some weeks have no volume recorded because they also had no writing time at all. The outlier in the upper-right was the last week of the project, in which finishing it was a priority.

Do you have favorite writing methods? Any suggestions for me about how to tweak my system? Bones to pick because I’m not doing Scrum correctly? I’d love to hear about it in the comments!