A question I’ve been getting a lot lately is whether UI designers should be part of the Scrum team and whether they should do their work as part of an agile sprint. It’s a big topic. So let’s dive right in.
The Two Goals of an Agile Sprint
There are really two things a team should be doing each sprint:
- Building new functionality
- Building new knowledge
We all know that teams have to build new functionality each sprint. That is, after all, the purpose of most projects--to deliver new capabilities into the hands of users.
But teams also need to build new knowledge. A team should finish each sprint smarter than it started. Sometimes a team learns things about a technology it is using or about how users view the functionality it has built. Other times, a team might learn something about itself and how it is performing.
Both goals are important.
What UI Designers Do During the Sprint
During each sprint, UI designers should pursue the twin goals of building functionality and building knowledge. Within a sprint, a UI designer will be helping the rest of team turn a design into implemented, tested code while simultaneously thinking about the next feature (or two) to be built. This means, a designer is both in the sprint and looking ahead at what comes next.
The result is something like what is shown in the figure below. This figure shows that while coding and testing one part of the product backlog, the user interface designers will spend some of their time (perhaps a majority of it) looking further down the product backlog at upcoming items. Yet, it remains one team working on one sprint at a time.
The UI designer’s top priority must be to the work of the current sprint. If a team member needs a clarification on a design for a product backlog item being worked on in the current sprint, the designer stops thinking about next sprint and answers the question about the work of the current sprint.
How About Other Roles?
Pause for a moment and consider everything I’ve just written about UI designers. But think now about product owners, analysts, database designers, architects or perhaps anyone with a significant responsibility to think ahead about what is to come on the project.
Everything still applies. It’s just a difference of the amount. Designers may spend the majority of their time building knowledge, but they’ll still spend some time building functionality. And one of the other roles I just mentioned may do the opposite. Every role on an agile project will split its time between building functionality and building knowledge.
Avoid Perfecting the Design Upfront
In giving the designer permission to look ahead, the agile team is not asking the designer to complete the design. Rather the designer should do just enough in advance that the product backlog item can be completed by the rest of the team in the later sprint when the team works on it.
At the end of the sprint, the team should feel that if they had received any less information from the designer, it would have been impossible to finish the product backlog item within the sprint. This means that some product backlog items may need to be looked at in massive detail (and more than one sprint ahead) whereas others may not need to be looked at in advance at all.
Additionally, any items a designer does look at beyond the current sprint should be chosen through discussion with the product owner. The designer wants to avoid working on something a product owner later deems unnecessary.
Does This Lead to Bad Design?
A common concern is that this could lead to a bad design. Wouldn’t it be better if the designer could think holistically about the entire system upfront? In next week’s blog, I’ll explain why working this way does not lead to bad designs.
