Sprint Guidelines

Sprints at Vizzuality

We run a lot of different kinds of sprint. Some are just a few hours, some are a few days. Each of them is a chance for us to get together, as a project team, to discuss the problems to be solved and start creating some solutions that fit the data, user and technology needs of the project.

In these pages we outline some of the best practices we’ve learned from doing each of these.

When should I do a sprint?

Kicking off a project with a client.

Many of our sprints take place at the beginning of a project, but not necessarily at the beginning of every project. Ask yourself the following questions before deciding to invite the client for a sprint

How big is this project? – For relatively small projects, with quite tight and well-defined scope, a sprint is less necessary
Is it a new project or client? – If it’s a new project with a new strategic partner, definitely run a sprint
Are they willing to come to Madrid? –Ideally they would bring a small team to our office: then it’s easier for us to bring in a wide range of staff as and when needed. –If not, think carefully about which staff to bring. Ideally we would bring a PM, research, design and dev/data.

Kicking off a project with our team.

Following that kick-off sprint, we then often hold a second internal sprint to push forward our thinking about website objectives, users, structure, architecture and features. To determine whether we need to do one, ask yourself:

First read these guidelines about kicking off projects. – Is your team informed enough about the project? Would they benefit from a 1-2 hour session discussing all the details of the project? – Have they had a chance to ask questions, and talk with each other about the different requirements?
Identify an outcome – if you did all meet for a few hours, what would you like to achieve? A first sketch of the wireframe? Clarity on feature requirements? A list of questions to ask back to the client?

-Identify who needs to be in the room to help achieve that. – Do you need the person that wrote the proposal, to help input client needs? – How many engineers should you bring (to make sure your ideas are technically feasible)? – How large is the data component of the project?

Find a time and place, then write an agenda.

Creating ideas for a new feature.

For our ongoing projects we are increasingly using sprints to better define new features and rapidly develop ideas to meet those needs. If any of the statements sound familiar to you, you may want to run a sprint.

The client is asking for a new feature but it’s not very well defined
A client is asking us to “come up with something creative”
The design team starts working on a feature but have a number of concerns about technical possibilities and data limitations

Writing an agenda

If you do decide to run a sprint, look over the following pages for advice about the kinds of activities you could run, and how to put a sprint together.

Preparing a sprint - Must Read before you go any further

Remember to think about Remote People. Identify which sessions (if they aren’t coming to all) remote people need to call into. Ahead of time, set up call-in information so they can contribute and make adequate room for it.