Visual Design implementation timing in Agile

Question

We work in Scrum with the caveat that we don't have a potentially shippable product at the end of each Sprint, instead requiring several hardening/stabilization Sprints before release.

One of the reasons for this is that our chief UX designer prefers that we'll complete all the visual work (such as colors, fonts, exact layout and controls) at the later stages of the project. On one hand it makes sense because a feature with decent UI based on a wireframe is usually good enough to receive feedback from the users, so working too hard on the final visuals and styles is not necessary for risk reduction. It might even be wasteful if the feature fails at usability tests or if after further user feedback we'll decide to change the visual design for the entire system, including features that were already implemented. On the other hand with this approach we will have a list of features that are not completely developed, and with the final polishes being left out until the final Sprints.

What do you think we should do? Should we go with the recommendation of the chief UX designer or should we go for a potentially shippable product?

Thank you.

Answer 1

Firstly, consider yourself lucky for actually having a UX designer :)

I'm not sure I agree with your definition of "shippable," though. Your definition isn't a bad one, it just might be a tad strict.

If you have all the functionality coded in with a decent (but still sub-optimal) user experience you're already on par with most production-grade software. I would consider this shippable.

Leaving the UX polishing/hardening sprint until later seems like a wise choice. It means the definition of the feature, as requested by the PO and users, is pretty stable. As such, its implementation is unlikely to change and the risk of having to redo the UX is acceptably low.

I see nothing wrong with your UX guys suggested approach. That is to say, as long as it doesn't have any negative side effects on other roles or processes. You haven't mentioned any so I'll assume there aren't.

Answer 2

I agree that deferring final UI decisions until later is the way to go in this case. Disclaimer: I am assuming, based on the question, that "final UI design" is a story in and of itself. Also, the fact that you have a dedicated UX designer lends credence to this since that person will be dedicated to working on these features.

If the user story states "Feature X shall do Y and Z" and is ugly, then fine, you can meet the requirements with some rough edges (placeholder icons, temporary color scheme, etc) as long as there is a separate story later on to fill in the UI gaps.

The most important thing is not to lose sight of requirements. As long as they are entered into your requirements tracking system, scheduled, and delivered, it really does not matter if you defer them until later. But if the UI is a risk factor, why work on it now and throw away hours of productivity later?