5 Rules for Integrating UX with Agile and Scrum

After more than a year of work, I’m thrilled to announce the launch of this joint effort between Scrum.org, Josh Seiden and myself. The Professional Scrum with UX certified class starts to answer the questions scrum practitioners from all disciplines have been asking. How does design work fit into sprints? What does “done” mean for non-software tasks? How many backlogs should we have? What is dual-track agile? All these questions are answered in the class and they are being offered worldwide now. See you there? Learn more.

(This article is a sequel to Here is How UX Design Integrates with Agile and Scrum published in October 2018. It also appeared first in my once-monthly newsletter. Sign up here and join 40k others.)

When I started my career, software came in a box. If that sounds weird to you, know that when I was a kid my dad would bring home the punchcards on which software came in the 1970’s. In both of those cases, more than 20 years apart, software was static. It had an end state. Fast forward another 20 years and these concepts seem ridiculous now. Today we build continuous systems that can be optimised indefinitely. This makes the question, “When are we done?” a difficult one to answer. We need the answer to this question because it helps answer other, even more important questions. Does the team get rewarded or chastised? Do we move on to the next initiative or not? Does the stakeholder get their bonus?

Product development teams using scrum (or any form of Agile development) have a clear understanding of the definition of done. It will often mean “the minimum criteria the product/service has to have to meet the needs of ‘the business’.” This regularly amounts to a checklist of features a stakeholder (or product owner) has mandated that is now 100% complete. Software developers often call this, “works as designed.”