Agile Web Design in an Agency: The PHX Renews Project – Sprint 2 & 3

Ben Kalkman posted this in
Inside Rocket Media
on June 3rd, 2014

This is the fourth installment in our documentation of our first agile project. This article will cover what’s happened since the completion of sprint 1 through the completion of sprint 3. To catch up, check out:

So much has changed at Rocket Media since I last wrote about this project. We bit the bullet and did some full-agency training on agile workflows, we’ve almost completed another, smaller project using this workflow and have started planning several others.

Oh and we hit our client’s deadline. We had their site up and running just in time for Bill & Chelsea Clinton to visit with the Clinton Foundation. And judging from the analytics, it’s a good thing we did since PHX Renews got so much (deserved) press.


Of course, there were still features that needed to be built, even if our minimum viable product was now live. So here’s what we did to get more of those built in 2 sprints (or, more accurately 1.5 sprints).

Sprint 2 - Preston goes on vacation

After completing sprint 1, we didn’t really have time to do a whole new sprint before the designer on the project decided to take a nice, 2-week vacation. But we didn’t want to sit idle that whole time, either. So we completed an abbreviated sprint. (Of course, the client was informed of this. Open and transparent communication with everyone on the project is paramount to the success of an agile project.)

In this sort of half-sprint we decided to tackle a few smaller things, namely a media section that would show all the media stories that PHX Renews has been mentioned in.

The process:

Our process stayed pretty much the same from sprint 1.

  1. We all met and planned out all of the tasks needed to complete the stories and they were assigned.
  2. Then we had a group wireframing session for the first story.
  3. We split up and got to work.

Here’s an example on how we were all able to work at the same time. The first story was to create a page on the site where excerpts of these media stories would live (and then link to the actual stories). Here’s what we all did after the wireframing meeting:

Content: Got to work organizing the collection of stories they had. I had to compile a title, summary, date and the link or URL for each story. As I was going through them all, I decided that I wanted to try to include a good pull quote from each story in addition to a summary, so I quickly met with Preston (the designer) to get his thoughts. He agreed and said he’d work into the design.

Design: While I worked on organizing the content, Preston already had a good idea about the shape the content would take, so he began designing out how that would look and be organized on the actual page. He knew the content would consist of a headline, summary, date, publication name and link. And then he adjusted the design slightly when I brought up the pull quote.

Development: At the same time, Garret was furiously typing away at his computer doing whatever it is developers do… He knew the basic content chunks that needed to be represented, so he began to code what he knew and slowly pulled more from Preston, as he designed it.

All the while, we all occasionally huddled around Preston’s desk for informal reviews of the work. We ended up with the page you see here: http://phxrenews.org/media

In addition, we added a module on the homepage under the timeline that links to the new page. We wanted to lend credibility to the project, so we included a few of the more prominent logos of the publications that had written about PHX Renews as well as a link to view all the stories.


This sprint also included some other minor updates, but as it was truncated compared to the others, this was the major outcome. On to sprint 3!

Sprint 3 - Doing a little bit of everything

At this point, we had two big areas left to build out – an events calendar and blog – as well as some minor things. We initially thought about spending this sprint completing everything we wanted to do with the events section (front end and back end).

Up ‘til this point, that’s how we had worked. We basically tackled our stories feature by feature. In other words, we did a whole feature, then moved on to the next. But after reading this great article on prioritizing user story maps, we realized the benefits “thin-slicing” our stories could have. Namely, that we could deliver more functionality to the client, faster.

Thin-slicing

So, for this sprint, we re-planned and re-prioritized. (And also began calling them “cycles” instead of “sprints”). We took each story and sliced them down to the bare essentials.

For example, the bare essentials of the events calendar, we decided, was a simple list of upcoming events, organized by day. They’d have a short description, title and date. We moved the “view events on monthly calendar” and other related stories to the backlog.

This freed up time for us to also tackle the blog and some other things (like a donate button). And we did the same thing with each of these features – sliced them down to the bare minimum of what would make them functional to the end users and PHX Renews’ internal staff.

The process

Again, this cycle followed a similar process from the others:

  1. We all met and planned out all of the tasks needed to complete the stories and they were assigned.
  2. Then we had a group wireframing session for the first story.
  3. We split up and got to work.
  4. We were constantly checking in with each other throughout the day.
  5. Repeat steps 2-3 for other stories.

Navigation decisions

In this cycle, we wanted to add “Blog”, “Events” and “Donate” to the main navigation along with keeping the “Contact Us” button that was already there. This became a big discussion point – do we address the off-canvas navigation now since we know we’ll need it eventually, or do we do something else that will likely get thrown out later?

We decided to stick with our mantra of only doing what was necessary for the current cycle. This cycle only had four items in the main navigation and so seemed like something we should be able to handle without an off-canvas solution on mobile.

Design and development met and hashed out a solution that wouldn’t take too long to implement, but still worked well. Basically, at a certain screen width, the buttons wrap and become a two-by-two grid.


This isn’t a long-term solution (we had plans for more navigation items) but works well for what we have completed in the project so far.

There seems to be a decision like this in almost every project cycle. Do you do something you know will likely be changed or do you try to complete the feature set you’re working on? We’ve gone with the first option every time and we think it’s the best one because many times what we would have built now is not what we end up building later (since we’ve learned more information).

In reality, this is the difference between waterfall and agile brought down to the feature level. Rather than completing something 100% without all the information, we are instead choosing to complete 100% of the information we have.

Other things

Much of this cycle became setting up the backend of the website. Since we now were introducing events and blog articles, we needed a way for PHX Renews to login and update them.

So between front end development of the events and blog pages, addition of the donate button and navigation changes, and setting up the back end, there was a lot more development time than design and content, so development had 6 days in this cycle while design only 5.

This seems to be contradictory to what most agile books/processes tell you (you want the whole team working all the time) so we’d be interested to hear other’s experience here. Is there usually more development time in your cycles than anything else? How do you handle it? Bring in another developer?

Project status

With the blog and events features set up, we’re now waiting on the client to input and update these things before we push them live (the donate update has already been pushed). We have one more cycle planned to flesh out the rest of the features, but want to see how the organization and website visitors actually use what we’ve built a little bit before continuing. (You know, so we can embrace change over following a plan.)

But keep an eye out, because we’ll be chronicling that cycle, too!

What have you thought of this series? Helpful? Not? Are we completely wrong? Tweet us @rocketmedia or let us know what you think, below.

Ben Kalkman

CEO/Founder

Ben Kalkman is the CEO, founder and owner of Rocket Media. When he has down time from running a successful company, being the father to 6 kids, running half marathons and purchasing every new Apple product that comes to market… eh who are we kidding, Ben has no down time.