Agile Web Design in an Agency: The PHX Renews Project – Sprint Planning

posted this in
Inside Rocket Media
on April 30th, 2014

In our last article, we explained why we decided to try a project with a more agile process and how we got there. Check that one out first, if you haven’t already.

This article will focus on the planning we did and the first phase (or sprint 1) of the PHX Renews project.

Story mapping

The core of planning for agile projects is the user story, which is usually written like this, “As a [audience] I want to [website task] so that I can [audience goal].”

The problem we felt with most sprint planning approaches was that they didn’t take into account the whole picture. You focus only on one piece at a time, which could cause you to lose sight of what you’re creating.

Luckily, we happened to stumble across the process described in chapter 8 of Agile Experience Design. In this process, (sometimes called story mapping) you start with your different audiences. Then, you list out the goals each audience wants to achieve on the website. From there, you break down the tasks needed in order to accomplish those goals.

Note: We started this project in our traditional process and had already gone through the discovery phase, so we had a lot of good information on the project. If starting the project from scratch, we likely would have needed to do some research (but not too much).

To keep this quick and easy, we used post-it notes stuck to a whiteboard, table or the floor (or a giant glass wall, in our case.)

Here’s a photo how this looked in progress:

Step 1: Identify key audiences

The blue sticky notes are the different audiences we’re trying to serve. In this case it was, city employees, Phoenix residents and the media (we also added one for “content editors”, since the website was also to have a backend so the organization could update content).

Step 2: Identify the goals of your audience

Under each blue sticky are the goals that audience wants to achieve (these are the salmon-colored stickies). For example, under Phoenix residents we had:

  • See what the project is about
  • Find things to attend
  • Contact PHX Renews
  • Donate money
  • Apply for garden
  • Become a better gardener
  • Volunteer my time

Step 3: List out the activities needed to accomplish the goal

Once we had all the goals we could think of for each audience, the next step was to list out the activities that will help the audience accomplish their goal. For example, under “See what the project is about” we listed out:

  • Read about the vision/history
  • See press coverage
  • View past events
  • See all locations
  • View galleries of what’s happening
  • See who is sponsoring it

These are things we learned from talking with Phoenix residents in the discovery phase of the project. We knew that many people walk or drive by one of the locations and then go online to find more info. These are the things they mentioned looking for.

We did this for every goal. Some had many tasks, some only had a few.

Step 4: Prioritize your goals and tasks

Once all the audiences, goals and tasks were on the wall, we shifted gears to prioritization. From what we’ve read, this (and much of the process) is usually done with help and input from the client (or “product owner” in agile speak) being in the room. However, we felt confident that we had a firm grasp on what our client wanted and needed since we had spent a lot of time with them in the discovery phase. Essentially, we collectively acted as the client.

This step proved challenging. Prioritization is difficult because there are at least three things to consider:

  • The importance of the task/goal to the user
  • The importance of the task/goal to the business
  • Dependence of one task/goal on another

You must balance your user’s goals with the business’ goals and objectives so you are pleasing the users and helping move the business in the right direction. In addition, some tasks must be built only after other tasks are because of how someone uses the website.

Step 5: Find your minimum viable product

Once we felt comfortable with our prioritization, the next step was to decide on a minimum viable product. That is, what is essential? What needs to be there in order for the website to function?

This is more of an art than a science. It’s tempting to throw some things in because “they’re sorta important and shouldn’t take too long.” But that’s not what we’re identifying here. This is the absolute minimum you need for your site to function.

It’s tricky, because you must again balance user needs and business needs. Really, there are two minimums – the minimum a user needs to use the site, and the minimum the business needs for the site to be functional. Hopefully these two closely overlap. (If not, you might have a business model problem and that’s bigger than most design agencies can help with.)

For example, on this PHX Renews website, we decided the minimum a Phoenix resident needed was basic information about the project and a way to contact someone for more info.

From a business side, the minimum was that people could find out about the project and want to get involved (and contact PHX Renews about it). There’s the overlap. The additional business minimum we added was that the website needed to show the different sponsors and partners that are helping make the PHX Renews vision possible.

That’s not really something many people come to the site to find out, but since the sponsors play such an important role in the project, it was necessary from the organization’s perspective.

Side note: what we learned

Our planning/scoping process now looks much different. We found that only looking at the project from a customer journey map perspective left out some key functionality/requirements from the business and technical side. We now have a much more inclusive process for this.

Step 6: Plan your sprints

Since this was our first time ever working like this (design, content and development all working simultaneously), we did things a little differently.

Rather than plan out every sprint, we only planned out the very first one. This was mostly because we had no idea how much we could do (we didn’t know our velocity). Instead, we took what we had identified as the minimum product and roughly estimated how long we thought that would take us (2 weeks working 3 days/week).


Our Kanban chart. This is later, after we’ve identified (and completed) some tasks.

From there we did the usual planning poker, created a burndown chart, converted our stickies to more traditional user stories and then placed them on our Kanban chart. A nice thing about story mapping is that it’s easy to convert the stickies into user stories. Here’s the formula:

As a [audience] I want to [task] so that I can [goal].

Using an example from above, this would look like:

As a Phoenix Resident I want to read about the history so that I can see what the project is about.

Step 7: Present to client

Like I pointed out earlier, the ideal situation is to have a client representative in the room during this planning. But that’s not always possible, especially for us as many of our clients are remote. In this case, we felt we knew enough to represent our client’s interests ourselves.

We presented our plan to the client. This was new for them, too, so we did our best to explain that this was simply the first phase. This lets us get them a working website much more quickly and efficiently. They were all over it and they agreed with our prioritization with only a few changes.

Step 8: Other preparation

Our goal was to start sprint 1 ready to go. So after the planning was done, we had a few other things we wanted to get completed before we began the sprint.

Design direction

We’ve been using style tiles to help us get design direction from clients for awhile now. While it takes some initial explanation, they do a good job of helping us get started in the right direction. We usually try to present two very different style guides so we can get feedback on both.

Here’s what we presented to PHX Renews.

Version A:


Version B:


They liked pieces of both. They liked the header of version A better along with the colors. But they liked the fonts and white background of the navigation in version B. This is exactly the kind of feedback we’re looking for at this point.

We talked about creating a new style guide that combines the pieces they liked of both, but decided that time would be better spent creating something that would actually exist at the end of the project (working software over documentation). We had what we needed to move forward.

Content started – We’re big believers in designing with real content. However, that presents a little bit of a problem because design will be starting on day 1 of the sprint. Our solution was to do some initial content ahead of time. I had already done several interviews with subject matter experts so had an idea of where to start. The content was rough, much like a sketch, but gave us more direction for the sprint.

Asset collection – This project was started and spearheaded by the Phoenix Mayor and I knew that they wanted him front and center to show that this was his vision coming to life. So we asked for photos of him and the project ahead of time.

Ready to sprint

Now that we have our user stories ready to go, our design direction and at least a beginning of our content, we’re ready to sprint! Keep an eye out for the next blog on our first sprint.