Digital Becca

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!