Why sprint cycles work for me

I’ve been lucky enough to inherit my job at a time when digital was expanding for Time to Change. 

Previously development work could be easily contained on an ad hoc basis, with emails back and forth to manage each project and few enough demands on a small team to make this possible.

Since joining, that’s changed and I needed a system to ensure workload and delivery schedules could be predictable, to satisfy the demands of internal teams as well as ensuring we could confidently meet our own commitments for development and growth. 

To achieve this I set up a sprint cycle system, managed through Podio, the online project management tool. 

How our sprint cycles work:

During each month I plan for the following sprint, working out priorities for development within our team as well as communicating more widely with the rest of the programme about ideas they might have to make their jobs easier or better respond to user experience issues they’ve identified. 

I then wireframe all the ideas to check everyone’s on the same page and collate all this into an amount I think can reasonably and logically be achieved in a given month, then email the developer with a headline description of the forthcoming work. This is an important step because it gives him the chance to identify any areas that might be more difficult to achieve or require greater resources that we have available. 

Once I have the go-ahead, I begin writing a detailed brief, dividing the work into sections (usually by team or area of the site) and within that splitting each component into individual tasks. I then email for a formal quote. 

Once the quote’s received and approved, it’s usually now the end of the month, I set up an e.g. “October sprint cycle” project on Podio for the upcoming month and upload the brief.

Once the first of the month ticks round, the developer starts work and usually completes the first daft on staging within a couple of weeks, having checked any small details with me via the project comment stream. Then I’m ready to begin first round user acceptance testing. 

Testing involves gathering all internal stakeholders and/or recruiting external user testers for bigger projects. It follows a similar process to briefing, I take the original brief and allocate each task a place in a UAT table in Word. Table headings are usually Job (component of work) Status (further work / ready to deploy)  and Notes (explanation of edits, etc) As I check each component and run through it with the team of testers, feedback and status confirmation is entered into the table and presented back to the developer.

Edits are then made and the same process repeated until the status of every job is “ready to deploy.” At this point it’s a couple of days from the end of the month. The developer deploys to live, giving us enough  time to work out any live environment bugs. Internal stakeholders are gathered again for signoff, they can make minor tweaks or alert me to any strange browser or mobile behaviour I can’t replicate, but all “actually can we also have this” requests are labeled as new requirements and will go into the next month’s sprint. 

Final tweaks are made then that’s it, sprint delivered, everyone’s happy and the whole thing begins again  the following month. 

I find this by far the easiest and most efficient way to manage development. It does lead to stressful spikes in workload, but as long as you’ve planned for those, built in the time and prepped everyone in advance, you’ll be fine.

I hope this is useful if you’re thinking about moving to the sprint model!

How Mind managed to publish breaking news, from 2011

Today a totally ridiculous coincidence happened, which I want to document somehow since it was fun to fix and will probably never happen again.
What happened:

When Mind launched their new website back in November 2012, we hired a keen team of digital volunteers to set about the tedious task of migrating content from one site to the other. Mind has a huge site, it was an endless and dispiriting task which we eventually decided to shelve, once the main content was over.

What we left behind were several hundred old news stories and blogs, back as far as 2010. Since then we’ve had a fair amount of internal and external pressure to bring the rest across, none more demanding than Moz.com and its hard to ignore report of 404 errors resulting from dead inbound links. Google is our master and we’ve been willing anarchists causing SEO chaos all over the internet, it was time for action.

A few weeks ago we decided to revisit the monster; exported the dead links in priority order and hired someone to migrate them. He’s been doing his job excellently for most of every day since he started, all’s been fine.

Today, we had an announcement to make, a lot of work went into getting as far as launching the story and the last bit was the news article – no big deal. The media team added the news story, naming it “Mind Media Awards: shortlist announced”, which naturally inherited the standard url format taking into account its structural position and title. All fine.

Elsewhere in the office, not 20 seconds before this happened, our patient content migrator had published a story, from the hundreds he was working through, called “Mind Media Awards shortlist announced”, a defunct page from back in 2011. Not a risk, right? Our CMS is smart enough not to let us name two pages the same thing, that would be silly. Except that he didn’t, there was no colon in his news story, so the website says “fine, these are different things, you can have both.”

But back in the 1970s, a group of nerds at Ascii decided characters like colons in a url pathway would probably confuse or break things, so decided to omit them, which means servers don’t read that they were ever there, even if good CMSs like Umbraco are fine with the whole thing.

At 4pm we tweet our release and point to the news story – right before some sharp-eyed tweeters alert us to the fact we’ve sent out a story from 2011. I’ve been managing the migration guy while my boss is away so know straight away what must have happened (and what a ridiculous coincidence! Of all the hundreds of urls on that list!)

To solve it, I set up a 301 from his content node to ours. Only of course it doesn’t work, because Umbraco knows they’re different, but the server’s thinking “why are you making me serve this page in circles you strange person, what kind of digital officer are you?” And I’m thinking “how on earth did this all happen at the same time?!”

The resolution:

We delete the migrated page, change the url of the news story and set up a 301 from the old to the new. Sorted. 15 minutes of team-awe ensue, while the rest of social media is none the wiser. Ace.