TorCHI Presentation: Sprint Zero and Agile Design
My co-workers Khan and Brian and myself went to the University of Toronto for a presentation at TorCHI. It was by Lynn Miller, a Senior Manager at AutoDesk (Maya, 3DSMax, AutoCAD, etc.)
The presentation was about Sprint Zero: the lead-up work that is required before a team embarks on an Agile project, or any project that has an iterative nature with many stakeholders.
Bottom line was that in her experience, and in conversation she has had with designers at UPA, CHI: Without the Sprint Zero and a Pre-Sprint, designers felt lost and products tended to “fail.” Historically, Agile organisations have dismissed the need for a Sprint Zero. In practice this has lead to designers that were disconnected from the final product.
For the rest of this summary, there are a few assumptions:
- Sprint One (first 2-3 weeks of development) typically doesn’t require much design.
- One project per designer. Any more than that, and it’s too much to deal with.
- All resources working on the project are full time on that project. The definition of “project” was larger than at my workplace, but perhaps typical for industry: ex. 5 devs, 3 designers, 3 QA, 2 documentation people, project manager, product manager.
Pre-Sprint Zero
Before Sprint Zero, there is actually a long pre-Spring Zero phase that that conceives of the project. This is where the Executives, Sales, etc. get involved to offer insight, feedback, and direction.
- It lasts several months
- Anwsers marketing and sales need, defines the business scope.
- Creates the research that is used throughout the rest of the process, specifically identifies Personas.
- It includes the competitive investigation.
Sprint Zero
Sprint Zero itself is actually not very long, but focuses on an aggressive building of common ground and understanding amongs the stakeholders. Without it, there’s a risk of no ”big picture” cohesiveness, early buy-in before complete understanding of the risks, and lots of ”thrash.”
- Sprint Zero Lasts 1-2 weeks
- No coding, no designing: just big picture envisioning so that everyone understands. Motto: “Maximise the amount of work not done.” – Create work, do not do any of it.
- Priorities are determined, though that they are difficult flush out in detail.
- Who is involved: PM, Design Lead, Dev Lead, Doc Lead, QA lead
- Get “just enough” that you have a “shared understanding” to begin design, development, test planning.
Steps in Sprint Zero
There are five steps to Sprint Zero.
1. Determine Shared Product Vision
If you haven’t done so yet, determine a vision for the whole product. This vision will not change throughout the life of the product. It helps keeps the project focused. TPM usually leads this, though external facilitation helps.
Do this by creating a “Vision Statement.” The statement can have the following format:
For … <users>
Who … <do stuff>
NAME <name your product something useful>
Is a … <thing>
That … <does stuff>Unlike … <competitor>
… <who does this>. (repeat)
2. Create a Project Objective Statement
Define an objective statement for this specific release. Used to make decsions against. Result of a 2 hour meeting, led by TPM.
“Remove the top obstacles that prevent people who download our product from purchasing it.”
“Kill 3DS Max.”
3. Flush out a Project Data Sheet
A product data sheet (of which there are many examples of online) create alignment between stakeholders Answers the Who, What, Why? Makes it easy to grasp fundamentals. Unlike the previous steps, lead by the Development lead, with all stakeholders involved.
The PDS will include:
- Personas
- Object Statement
- Client benefits
- Tradeoff matrix: Excel (perfect, immovable), Improve, Accept (flexible) vs. Features, Schedule, Resource, Stability
- Specific features defined as “able to ..” statements. “Colour picker” is not a feature. “Able to pick colours while drawing” is.
- Milestones and schedule.
- Prod architecture and performance considerations.
- Risks and risk management.
4. Define an Operational Model
At this point, you can get the team ready to go. Physical planning is very important. Whiteboards, decisions on what remote software to use, determine what software for note taking. Physical environment is often neglected in planning. Determine roles and procedures for the project.
- Led by Dev Lead.
- Determines meeting times and format (stand-up, scrums, formal, etc.)
- Good time to review “lessons learned” from last release: well, didn’t go well, surprises, expectations, etc.
- Who fills the customer role?
5. Have an Initial Planning Meeting
The first planning meeting is pretty intense. It results in a speculative high-level schedule with sprints laid out. It establishes priorities and accepted timeframes. The “Able To” statements are broken down into chunks, which results in a planning board with story cards: Estimations, ”Able to” chunks, timeboxed. List out employee vacation.
Once you have a first run of the schedule laid out, expect things to be more mutable as you move left to right.
The pieces on this schedule are called Story Cards and Feature Cards
- Tight estimates in “Feature Points.” FPs are kinda like a “person day” but adjustable to the role, person, etc. Takes care of things like overhead, quantifiable to figure out your “velocity.”
- Story card is higher level, feature card is subset of story card.
- Each card is associated with a developer.
- Each card has an acceptance criteria from all the stakeholders: Docs, QA, Dev, Design.
- User Story cards can be used to illustrate strategy and tactics, but with loose estimates. There are things that are a bit too big or in the future to even break down. Usually things that can’t be estimated are user stories.
- Risk cards are used to identify specific risks. Make these red. You can have specific risk cards, such as design risk cards, external dependency card, engineering/dev risk card.
These cards are place on the schedule in a timeline. Watch for janitorial staff re-prioritisations (ie. take pictures). The physical cards are moved to prioritise:
- Product requirement: must to nice
- Workflow: essential to additional
- Development Risk: high to low
- Dependencies: many depending on it to none
- Design risk: high to low
… and that’s it. At this point, you’re in Sprint One and you’re following your Agile method with a shared understanding and lots of decision-making material.
Best Practices for Design in Iterative Environments
There were a few best-practices that could be taken away by designers, irrespective of the SDLC.
Design is always being done for the next cycle, before the developers ask for it. Special attention is paid to future high risk items. This gives you time, and reduces pressure.
You have to pre-plan all your client visits, preferably during Pre-Sprint Zero. Assume that you’re going to use them. Customers don’t mind seeing you over and over if you show them progress every time you see them.
Always go on site with at least two people: a project manager to see purchaser/client, and another UX person to get end-user access. Those needs are different, and impact your design in different ways.
Every once in a while offer a more public larger release, such as a free preview, feature complete alpha, etc. This may be hard to do, but is very worthwhile in holding trust and engagement from the customer.
-
Mehdi
-
dariusz
-
jonathan