Design-led planning in an agile model
Design teams at Fidelity are improving the scheduling and prioritization of their work by making planning a design-led activity
I’m a member of a design team that works with 4 different Agile product teams. Each one of those product teams depends on us to conduct research, conceptualize products, design interfaces, and build interactive prototypes. Planning this amount of work would be hard enough if we were operating as a single, embedded product team—doing it as a resource that supports multiple product teams at the same time can feel daunting.
Dependency meetings
So how do we decide what to work on and when to work on it? We start by conducting dependency meetings with each of the product teams we work with. The meetings are scheduled at the beginning of each quarter and the goal is to establish the following things.
1. An understanding of the products
Before our team can commit to any work we need to understand the products we will be working on. Sometimes we start designing interfaces without fully understanding what we are working on. The reality is that our team can’t determine the correct design activities to conduct if we don’t understand a few high-level things about the products:
- The business goals
- The product team’s roadmap
- The users we are designing for
2. The state of the products
The work our design team does also depends on where the products are in the product development lifecycle. To get a better understanding of this we ask the product teams these questions:
- Does the product currently exist?
- Are we measuring the product?
- Has any research been conducted on this product or a similar concept?
- Has any design work been done?
- Has any development work been done?
Answering these questions helps us determine what we should be working on in the quarter. Sometimes a product is just a hypothesis in a Word document and the next best step will be to conduct a Right Problem research study to learn the unmet needs of our customers before we start designing the solution.
Other times a product is much further along and the only work that needs to be done is minor updates to an interactive prototype that has already been built. In this case we know that product won’t require a lot of work and our team won’t spend a lot of time or resources on it.
3. The design work
The work our design team can and can’t commit to doing will vary based on the structure of our team. Last year our team operated without a dedicated researcher for 6 months, so we couldn’t commit to as many research studies as we would have liked to during that time.
Not being able to commit to everything is totally acceptable. It’s better to set that expectation during planning, so product teams can accurately evaluate our team’s capacity to do work and adjust their timelines if needed.
4. A schedule of the design work
The last thing we do in the dependency meeting is create a schedule of when our design team will conduct and complete the work we committed to in the quarter. I’ll demonstrate how we’ve been doing this in the next section.
Visualized planning with Mural
Our team has had great success using Mural to visually represent the work we commit to for the entire quarter. Mural is an effective tool because it’s simple to use, collaborative, and visual. The Mural we create during our dependency meetings looks like like this:
The Mural is composed of 3 main components:
- Epics
- Sprints
- Stories
These are all terms used in Agile. I’ll do my best to describe what each term means so you can use them or create your own labels that work for your team.
1. Epics
Each row in the Mural represents an epic and the name of the product team building the epic. Think of epics as large bodies of work that can be broken down into specific tasks.
2. Sprints
Each column in the Mural represents one sprint and the duration of the sprint. Think of sprints as short, time-boxed periods when your team works to complete a set of tasks.
3. Stories
We use sticky notes to represent the work our design team will commit to in the quarter. Each sticky note represents a small body of work, no larger than the size of an Agile story. We work with each product team to write and position sticky notes in the sprints (columns) to schedule when our team will conduct that work. The scheduling of our design work depends on 2 things:
- When the product teams need the work completed
- Other work our team has committed to for the quarter
To speed up the process of writing and scheduling work, our team has created a set of template sticky notes based on the type of work we do most frequently. This saves us from having to write a new sticky note every time we add a task that is typically used in most stories. The template sticky notes don’t cover everything, so we always have to write some in manually.
We’ve also found it really effective to color code the sticky notes based on the type of work they represent. This allows us to quickly see where our efforts are being spent and signals where we might be over- or under-capacitated.
- Yellow = Research
- Blue = Design
- Pink = Development
For example, if a sprint has a ton of yellow sticky notes it’s clear that we’ve scheduled too may research activities and some of that work will need to get moved to a later sprint. In the example below you can see that we need to adjust some of our research work from sprint 2 to sprint 4 or we’ll be at risk of not being able to complete the work we’ve planned.
By the end of the planning, our design team and each product team have a clear view of what we will be working on throughout the quarter. In an Agile work environment, priorities often shift, so this schedule isn’t set in stone but it’s a great starting point.
Closing thoughts
It’s important to make the planning of design work our first priority before we begin the tasks of researching, conceptualizing products, and building interfaces. My team has found Mural to be an essential tool in this planning process because it allows for distributed teams to collaborate. Comprehensive planning allows our design team to smoothly coordinate with Agile product development strategies and effectively support multiple product teams at the same time.
#FidelityAssociate
