Implementing UI Design in Scrum
I’ve been looking around trying to find some good advice on how to integrate user interface design into and agile/Scrum process, but I haven’t found a lot helpful, practical material.
From what I’ve seen, there are two primary options:
1. Design as-needed during a sprint. This is definitely the more ‘agile’ approach, but it can create issues. Either your going to have to come up with a way to do some very rapid design work (back-of-the-napkin / whiteboard kind of stuff) or you may find your developers waiting for a few days at the beginning of a sprint while your designer comes up with stuff. This puts the designer under unfair pressure, and may result in your developers twiddling their thumbs.
2. Design one sprint ahead. In this scenario, your designer will work on design concepts for the next sprint during the current sprint. This is less agile, but gives your designer some breathing room. This is helpful if you have designers who are uncomfortable with a very rapid design process.
My preference is option one, but we have found that that introduces too many constraints on the process. Given that our project priorities aren’t changing rapidly, we can manage this level of pre-sprint work. Our business analyst also spends some of his time working on the next sprint, so it already fits a pattern we have in place.
Designers fall into the same category as business and quality assurance analysts — no less important than the developers, but they do play a ‘supporting’ role, and these roles aren’t expressely prescibed by Scrum. In the end, we’ve chosen the path that works for this team for this project. I think on a more ‘agile’ or frequently-changing project, we’d have to find a way to incorporate design into the same sprint. That’s a challenge for another day.
There are 2 principles of scrum which could have a bearing on the way that you would try to resolve this: Cross-functional teams and the ‘sashimi’ principle of delivering a full piece of functionality.
I don’t think its wise to view the designer (and especially QA) as support roles within the team. There are no support roles because everyone should just be a team member with a balance of skills across the team. A specialist like a designer may have a specific skill that the team leverages, but in a pinch they should be assisted by any other team member or assist with tasks that may not be their specialty. It also means, counter to most design wisdom that the design process should be one of collaboration.
It’s clear that design is important and should be included in the team’s ‘Definition of Done’. As part of the ‘Inspect & Adapt’ phase, the team as a whole should address the squeeze on design. This may mean that wireframes and rapid UI design would be a collaborative first phase of a story delivery.
This initial session and then technical division of labour would mean that the dev team should be able to start working on the back-end functionality and the designer can produce the final UI. The integration should be supported by tooling or a chosen architecture. If it isn’t, then this is a major impediment that the team needs to resolve in order to improve their productivity. My recommendation would be to possibly ‘force’ this issue to the fore by reducing story size and possibly even iteration length until the pain becomes a focus for the team. Note: the team as a whole should feel this pain, not just the poor designer. The team should also be responsible for finding the resolution.
Some future sprint prep work is necessary in any scrum team, but I would watch to what level it creeps. More than about 10% of a person’s time spent on activity outside the immediate sprint goal is a sign of a split focus. It also makes the priority less clear. The team pushing collectively for a single goal is the essence of scrum’s strength, and indeed the basis of its name, after all.
All reasonable points — thanks. I especially agree with the idea of forcing the issue to make everyone feel the pain and therefore motivate the team to fix it — this is something we’ve done in the past with some success. As it stands we’ve come to a reasonable balance. Added to what I stated in the original post are the issues of how individual personalities come into play — sometimes you need to make adjustments to fit that. As long is it doesn’t hurt the team or the project, I’m willing to give some leeway there. We’ve found a solution which works for us, meets our needs from the perspective of our goals around delivering the system and the level of agility we need to see.
I do still think non-programmers, to some degree, play a kind of supporting role. Absolutely they’re all a part of the same team, and everyone should pitch in where they’re needed (and they do), but the fact is, the programmers are the engine behind the project. It’s why I have four of them, and only one QA, one BA, and one designer. This doesn’t make other team members or their contributions less important.
I look at it a different way. To me, there are some members of the team who also must serve in roles outside of the team. Someone who does QA would be one example. There are duties, such as testing, that fall under the purview of the team’s sprint commitment. QA should be maintaining reports on the status of quality of the product. They should be maintaining a backlog of quality items, such as defects. They should be helping the product owner write exit criteria for stories. All these are duties that do not exist on the team, but must be done.
Designers are in a similar situation. Not only must they work on the team to develop the product, they are responsible for providing guidance on product features. Design comps should be part of the story-writing process. Final implementation of design elements should be all that is left during the development sprint. Ideally, there will be some latitude for the designers to make some changes during the sprint, but they should still be working closely with the PO to determine what the product features will look like.
In one Scrum shop I belonged to, this approach worked rather well. Providing a visual comp to accompany a story went a long way to disambiguate it. It led to better stories, better estimation, and better quality of product.
Good ideas — I appreciate it. I like the idea of high-level design comps being attached to the stories. With the big project I’m working on, we have a couple hundred stories so it wouldn’t be something we could apply to all the stories. I’d like to have comps attached to central stories when we estimate them — it would help the team get on the same page.
Something else to consider is, if the stories have been broken up into small enough chunks of work, the design of each piece should not take all that long. Developers can usually get going on a piece of functionality with a complete visual design. A down-and-dirty wireframe on the whiteboard will do, in most cases.
One huge benefit of in-sprint design is the organic nature of full team collaboration. I believe doing one-sprint-ahead design falls under the scrummerfall heading. Discussing UI choices with the entire team present goes away when the Dev/QA folks are focused only on implementation and designers are focused on what’s ahead.