UX in a scrum environment.
Hi Gang,
Thank you for the add.
I am responsible for creating a beautiful user experience for thousands of end users. Our project is using the agile scrum methodology and we have just started. Typically, I would have use cases that define the system prior to design a user experience, but with the Agile approach, this is not the case - as you already know.
We are moving along, bit by bit, but the process feels strange to me because it is very hard to define a user experience when you do not understand the entire system. Has anyone else come across this? What are your thoughts. I have been on projects that use Agile in the past, but the requirements were defined before I was brought on.
Any help is appreciated.
D.
How does user experience relate to the product in this case? Why is UX being considered in isolation?
Hi Ian,
I'm sorry, but I'm not sure I understand your first question. Can you please rephrase?
For the second question, I would say that UX is not being considered in isolation, but instead, the opposite. Part of each sprint.
Thank you,
Doug.
If UX is part of each Sprint, why do you feel the need to understand the entire system? Each Sprint should be planned so that only one feature-complete increment at a time has to be considered. The scope of each increment ought to be agreed between the whole Developnent Team and the Product Owner.
Hi Ian,
I would like to understand the entire system so that I can make informed architectural UX design decisions that impact the entire system. For example, there is a need for a common navigation throughout the application. To me, doing this in Sprints is risky in that it is not encompassing a whole system view. If I was to draw a parallel with building a home, I'd design the entire home and not design & build one room at a time. Who knows, I may have a bathroom in my Kitchen in that case.
I must be missing something here and appreciate your guidance. My dev friends love this approach. It surprises me as well, because I'm unclear how they can properly build out an architecture in their code with understanding such a small amount of the requirements at a time....
The problem you are describing seems to lie at the interface between Design Thinking and agile practice. My recommendation is to approach it that way. There’s no standard model and opinions on how to handle it vary, even among experts.
- One school of thought is to encompass design thinking within each Sprint, experimenting rapidly with such things as user experience, and validating assumptions through incremental releases, however small. That could mean validating assumptions about common navigation via a couple of small but telling scenarios, for example.
- Another school of thought is to accommodate Design Thinking into Product Backlog refinement. In effect core design decisions, such as a common UX navigation approach, must be reached in order for items to be “Ready”.
The former model is conceptually cleaner as it brings UX matters squarely within empirical process control. The latter is arguably more practical, in so far as it may demand less agile maturity at a Sprint execution level.