For website or application design projects that employ an Agile Scrum methodology, I often like to begin the project with a “Sprint 0”. Sprint 0 is a unique iteration that happens right at the start of the project to allow for some foundational architecture to be established, the requirements to be clarified, and for the wireframes and designs to get slightly ahead of the development. Then, once the project gets “properly” underway using agile, the team members focused on coding, theming and QA are ready to hit the ground running from day 1 of Sprint 1.
But what exactly happens during Sprint 0? Does doing a Sprint 0 mean we are leaning towards a hybrid methodology (waterfall/agile)? Are we cheating at Scrum by doing it?
While I would say that an initial sprint dedicated to requirements analysis, architecture, user research, and process modeling does nudge us ever so slightly towards the waterfall end of the spectrum, it’s only a single sprint, and can save your coders from sitting idle during the first week or two of the project.
To better understand the benefits of conducting a Sprint 0, we can break up the iteration activities into 4 phases made up of two strategies of divergence and two strategies of convergence. These phases are:
- Gathering (Divergence)
- Synthesis (Convergence)
- Ideation (Divergence)
- Design (Convergence)
Phase 1: Gathering (Divergence)
The Gathering stage of the process aims to uncover and document information about the project that may not have been initially captured, and also to make sure the project goals and objectives are clear. This stage typically consists of stakeholder interviews, user research, observations, and competitive analysis. It is meant to be a collection exercise.
Phase 2: Synthesis (Convergence)
The Synthesis stage aims to analyze and make sense of the data that was collected in the Gathering stage. Detailed requirements can be fleshed out and turned into Epics in the product backlog, or even user stories if the information is granular enough.
From the user research we can build user models (use-case diagrams, personas, etc.), focusing on their goals and the activities they engage in related to the project. The information gathered should allow us to construct user scenarios on how the site or application will be used and impact the lives of its users.
The models provide firm footing on which to base the design decisions that result in the ideation phase.
Phase 3: Ideation (Divergence)
The Ideation stage involves the further breakdown of the Epics and models developed in Synthesis into user stories that illustrate the functionality to be developed in easily manageable units. The Product Owner works closely with the stakeholders to prioritize these user stories to ensure that the maximum value is delivered at the end of each future sprint.
The Ideation phase is a good place to start developing the system’s information architecture, building its taxonomy, menus, labels, content types, etc. (as needed).
Also during the Ideation phase we start iterating wireframe designs for the site or application layout and user interfaces. Wireframes can be as simple as drawing ideas on paper, or higher fidelity, made using programs like Balsamiq or Omnigraffle to create digital – even interactive – designs.
Phase 4: Design (Convergence)
The Design phase is where we start to refine our wireframes, producing higher fidelity designs that will be used by the front-end developers come the start of Sprint 1. Our UX designers produce process flow diagrams to map out how users are expected to interact with our system. And we get our graphic designers involved here as well to begin iterating over ideas around look and feel, colour schemes, iconography, and typography.
During the Design phase you could also get your system architects to set up the technical foundation, such as dev, staging and development servers, Git repository, and installing the core software (like a CMS if the project is using one).
Conclusion
Having completed the 4 phases mentioned above in a Sprint 0, the Agile team should be well prepared to hit the ground running come the start of Sprint 1, even if the very first activity of the day is Sprint Planning. It is crucial though that the Product Owner be heavily involved throughout Sprint 0 and be a key leader in prioritizing the backlog with stories that are immediately ready to be worked on. In many organizations the role of Product Owner is taken on by the business analyst or UX designer, who will probably be the individual leading the Sprint 0 information gathering anyways.
The last thing I will mention is a small caveat on the timebox around Sprint 0. If you are running 1 week sprints, that doesn’t give your BA or UX person much time to gather and analyze the initial requirements, enter epics and stories into the backlog, prioritize them, and deliver wireframes and flow diagrams. But it can be done. In a 1 week sprint scenario, the time devoted to each of the stages is simply reduced. The main objective is still the same, which is to establish enough of the groundwork to get the requirements and design slightly ahead of the development.
Happy Scrumming!
