Planning Sprint Zero

Once your stakeholders and engineering team approve your north star it's time to get to work. Here's how we mapped out the design team's sprint schedule for UX and UI requirements at Lifesize.

  Our “sprint zero” planning exercise made visual a realistic timeline for when finished apps would get to customers.
 
 

Yes, design can be Agile!

Stakeholders new to big software projects may be unaware design can fit into Agile. They often ask designers finish their work before "bothering" developers. While well-intentioned, the strict waterfall approach means:

  • you miss opportunities technical team members bring to the table,

  • requirements become stale after several sprints as small changes add up,

  • and time wasted on re-design when requirements aren't workable.

Just enough design for Buy-In is Not Enough to Build

On large projects you can replace waterfall "big design up front" with a more Agile “just enough design." When I worked on the app redesign at Lifesize this took the form of a prototype that served as our north star.

The north star satisfied several key goals. Executive stakeholders could understand and sign off on the design and experience vision. Product owners could break the project apart into epics and user stories. Engineering had enough direction for high-level pointing estimates.

While we had an outline of our user stories, the stories lacked enough detail to book them for a sprint. Our small team had months of work on wireframes, flow diagrams, and UI redlines ahead of us. It was time to plan.

Gathering our Ingredients

Our goal was to fill the Engineering team's backlog no more than two two-week sprints ahead of their work. To map out our sprint zero work for the project, we needed:

  1. The user stories/high-level features

  2. Story ordering

  3. Story pointing estimates

  4. Team sprinting velocity

  5. Post-it notes (optional)

In other words, we needed the Engineering team's to do list and the order they planned to tackle those items. They gave their best guess in the form of a numeric score (or "points") on how much work each item would take. We then compared that to how many points of work they finish each two-week period.

Creating the Map

I wrote each sprint on a large Post-it and noted events that might affect the team's workload (staff holidays, etc.). We wrote each feature's name on a smaller Post-it along with its point estimate and lined them up in order. As a team we then pulled features from the front of the line to fill a sprint until the sum of points met the team's max.

The result was a visual representation of the project's development effort and timeline. Not only did this map help us plan the design team's work, it brought useful insight to other teams. Engineering, Product, and Design referenced it in sprint planning meetings. The impact of schedule changes or story order were immediately obvious to all.

We retired the map a few months later, but it was invaluable to the early stages of the project.