Every doc sprint is different

We’ve just held our second doc sprint. It was very different from our first, but just as awesome. For me, the best thing about both sprints was the people. Getting to know people and working with them in the intense focus of a sprint is great. Hearing and seeing their ideas for our documentation is simply inspiring.

We ran the doc sprint concurrently in Sydney and San Francisco on Thursday 4th and Friday 5th November. There were also a number of people working remotely, as far flung as Israel and Moscow. As you can imagine, the word “concurrently” is a bit fuzzy, with all those time zones involved!

We had different aims for this sprint: In the February sprint we worked on developer documentation, whereas this time our target was user-focused quick start guides. The sprinters were different too…

The people

Every doc sprint is differentFor the previous sprint, we invited developers from inside Atlassian and from our plugin development community. This time we had developers, technical writers, support engineers, business analysts and all sorts. They were Atlassians, partners, community developers and also people who use our products and were generous and interested enough to take part in the doc sprint. Here’s the list of attendees. We’ll be putting up the photos in our Hall of Fame soon!

The photos are also on Flickr. Search for the tag #AtlassianDocSprint or look at these sets:

The results – “awesome” is the only word for them

We wrote 25 guides consisting of around 42 pages, some complete and some needing more work before we can publish them. A few people started creating videos to supplement their guides too.

Every doc sprint is different

In addition Jim Intriglia worked on his guides to using JIRA on Linux, which he will publish on his blog soon. Jim also wrote a very nice post about the doc sprint.

I’m amazed at the energy and skill that people put into their guides. People also let us know that they enjoyed the sprint hugely. We put a lot of work into the planning, and especially into creating the wish list of guides to write. This really paid off. Congratulations to Giles, who organised this sprint!

Chocolate, haiku and fun

Although every sprint is different, some things never change. Inevitably there was chocolate.

Every doc sprint is different

To the great delight of all.

Every doc sprint is different

Joe’s Tim Tams went missing very early on in the proceedings. All that was left was a lonely half a Tim Tam perched on top of Joe’s Dell. I dubbed it “Eric the half a Tim Tam“.

Every doc sprint is different

Everyone knows that chocolate and haiku are a match made in heaven. But… just how many syllables are there in the word “chocolate”? Add the sublime technology of IRC, and this is what you get:

Every doc sprint is different

Take a look at the doc sprint haiku competition. This was the winning entry, by Daniel Green in Israel:

No time to eat now.
Should be writing more content.
Too late, never mind.

Retrospective and what I learned from this doc sprint

At the end of the sprint, we held a half-hour retrospective session (one in Sydney, one in San Francisco) where people could tell us what they think went well and what we could do better next time. Here’s the doc sprint retrospective page on the wiki.

Having the wiki as a tool for the retrospective, as well as for writing the documentation itself, was very useful. Remote sprinters just added their feedback by editing the retrospective page itself, if they could not attend the session in person or online. Some people were working in weird time zones.πŸ™‚

We’ll be summing up and voting on the results over the next week or so.

From my own point of view, I learned a lot from this sprint, as I did from the previous one too. For me, the main learning points this time were these:

  • A number of sprinters said how valuable it had been when they were able to collaborate with a technical writer, to “get the words right”. It was very heartening to hear how people appreciate our skills. We had consistent feedback that people wanted to “pair” with us more.
  • Leading on from the above point, it may be a good idea if the technical writers don’t have specific documents to write during the next doc sprint. Instead, they could spend their time pairing with each of the other sprinters in turn. This is especially valuable if the other sprinters are not technical writers.
  • We had made a specific decision for this sprint, not to create templates or detailed guidelines. We wanted to leave people free to design their guides in any way they chose. Judging from the feedback we received, that may not have been the best decision. Instead, next time we will consider light-weight templates and style guides as we did for the first sprint.
  • This doc sprint was only two days long, so there was only one webinar in which the two main time zones coincided (Sydney and San Francisco). That was a pity. It would have been nice to have more contact with the San Francisco sprinters, and with everyone else working remotely. Our previous doc sprint was three days, and that seems to be a good period.
  • The final day of this sprint was a Friday. That meant that the San Francisco people were finishing the sprint on Friday afternoon, which was already Saturday morning here in Sydney. Very few Sydney-siders were watching.πŸ™‚ Instead, perhaps we should aim for Monday to Wednesday for our sprints.

Let’s leave the retrospective with a look at this feedback point:

VERY concerned about the theft of chocolate during the sprint πŸ˜‰ Should encourage people to lick their chocs when they get them.

We can all guess where that one came from!

A man and his chocolate are not long parted

Joe was reunited with his Tim Tams. I’m not sure what happened to Eric, but I’m guessing it’s a tragic yet heartwarming tale complete with much philosophy and soul-searching. To bee or not to bee, half a Tim Tam philosophically, ipso facto may just bee a conundrum too profound for this doc sprint. Perhaps we’ll solve it in the next.

Every doc sprint is different

Of technology and trees

Some sprinters were surround by technology. Here we are in Sydney, hooked up to San Francisco via a video conference (television on the left) and to remote sprinters via a webinar (screen at the back).

Every doc sprint is different

Some sprinters were surrounded by beauty.

Every doc sprint is different

Thank you Jim for giving me the opportunity to add a tree or two to this post.πŸ™‚

About Sarah Maddox

Technical writer, author and blogger in Sydney

Posted on 7 November 2010, in atlassian, technical writing, trees and tagged , , , , , . Bookmark the permalink. 6 Comments.

    • Hallo Katya
      Nice post, you too! It was great to “meet” you on the doc sprint wiki, after swapping blog posts and comments over the past many months. I’m so glad you could take part. I love your enthusiasm and passion for wikis and for tech writing.
      Cheers
      Sarah

  1. Great post and pictures on the Doc Sprint, Sarah. So much good information on the Doc Sprint Wiki; much to read and more people to meet that have common interests in developing docs for Atlassian products.

    I posted my “JIRA on Debian Linux Admin Reference Guide” on my blog over the weekend. It contains two embedded links to screencasts (in the Introduction section) that I created to introduce people to JIRA and also the use of formal specifications (workflow spec) when developing custom JIRA issue management applications. I’ll be adding new screencasts to future updates of the Guide, as well as adding more info and resources as the year progresses.

    The much larger “JIRA on Linux Admin Reference Guide” will be much more comprehensive, covering installing JIRA on other Linux distros (Fedora, CentOS). It will contain more screeencasts and additional resources geared toward the JIRA administrator that has to maintain JIRA on several different UNIX/LINUX platforms.

    Onward and forward!

  1. Pingback: Tweets that mention Every doc sprint is different Β« ffeathers β€” a technical writer’s blog -- Topsy.com

  2. Pingback: New guide to developing technical documentation on a wiki « ffeathers — a technical writer’s blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: