Many creatives such as graphic designers, photographers, and product designers live in a world of chaos. On any given hour of any given day, someone in the organization will email, chat, or stop by their desk to make a last minute design request. Could you create this quick poster for our recruiting event tomorrow? Can you squeeze in a design for a new confirmation modal in our the app? Can you create a quick summary video from our offsite yesterday so I can share it with the team tomorrow?
Accompanying the ever-constant stream of requests is a lack of clear priorities. This forces the designer to make emotionally-driven prioritization decisions multiple times per day. Should I prioritize based on who asked me? In that case, does the CMO win because of rank or does the nicest person win? Should I prioritize based on urgency? Is that based on a real or imaginary deadline or perhaps just the sound of urgency in their voice?
Without clear priorities, aligned across stakeholders, everyone loses. Some of the work gets done quickly while other work slows to a crawl–eroding stakeholder trust. Even more concerning is that the chaos starts to negatively impact the quality of the design work. This couldn’t be more true in the world of product design where ad-hoc designs lacking customer research and testing will not only reduce usability of the product but will frequently cause engineering rework down the road.
The end result of this vicious cycle is an exhausted designer, who feels on the one hand like a hero for smiling and saying “yes” to a request and on the other hand feels like an unappreciated short-order cook who just can’t keep up.
Good News! A Solution Already Exists
The amazing news is that these same process problems have already been solved in another part of your organization! Software development teams have been transitioning over to agile methodology for years in order to increase alignment, improve predictability, and ultimately increase the quality of products being developed.
A big part of the success of agile is the sprint planning process, because the ritual of planning work as a team creates a natural demand for request queuing, prioritization and capacity planning conversations. These are the very same benefits that designers and creatives need so desperately.
So Why Aren’t Designers Already Doing Sprint Planning?
The last two UX teams that I’ve led did not start out doing agile sprint planning, including the product designers who were embedded in an agile-practicing software development teams and regularly attending agile team meetings. Why?
Misperception #1: Sprint Planning Will Curb My Creativity
Some designers worry that planning and estimating their work will stifle their creativity and prevent them from going deep on an idea. In fact, if you do a great job of planning out design work—really honing in on your estimation precision—you’ll find that you take on the right balance of work and give yourself the breathing room to do your best creative work, rather than rushing around from project to project.
Misperception #2: Design Work Can’t Be Estimated
One of my lead designers at my last company said that “creative work just isn’t the same as engineering; it just can’t be estimated.” I actually think that engineers are also quite creative in their work. For example, there are likely just as many different ways to write a function as there are to solve a design problem. And ironically, the excuse of not being able to estimate work is exactly the same excuse that developers give when they are fearful of transitioning to agile. Accurate estimation does take practice so you should plan on completing at least 3 sprints to learn this new skill.
Misperception #3: My Stakeholders Need Support For Ad-Hoc Requests
It’s absolutely true that ad-hoc requests have their rightful place in organization and planning. We’re human and can’t anticipate every detail of what we’ll need for a given project. However, the vast majority of requests that come in today as ad-hoc, could have in fact been anticipated weeks in advance through proper planning techniques. Even after you’ve “trained” your stakeholders on your planning process, it’s totally okay for you to leave a couple of placeholder slots in your sprint plan for truly urgent, ad-hoc requests.
Misperception #4: My Engineering Team Won’t Let Me
As a product or UX designer, why would your engineering team not want you to add your user experience work to their sprint? Perhaps it’s a fear that it will “mess up their metrics” by including non-development work. But not to worry, because these metrics will find a new normal after a few sprints. With that said, product designers and researchers can still achieve the benefits of agile planning by using your own tool or project as long as you meet with your product manager and ideally your delivery team to collaborate on your plan.
Misperception #5: I Have No Idea How to Do Agile Planning
If you’re not accustomed to working closely with engineering, you may be in a situation where agile feels like a secret cult with weird jargon and strange rituals. But don’t let that deter you! Designers have their own set of strange jargon– just imagine how a developer would react to hearing you talk about kerning for an hour.
I hope I’ve alleviated your fear of agile sprint planning. It will not hamper your creativity. Rather, the process achieves the opposite because sprint planning removes the resulting stress and additional time required to prioritize projects. And that means you can focus on the work itself. Keep an eye out for my next blog post which covers basic concepts of agile spring planning and common jargon.