How can developers and designers work together in an agile way?

Question

A designer delivers a mockup to a developer. That mockup is delivered as part of the story, but may or may not be considered actual acceptance criteria. After all, the mock may not even look finished or behave correctly. So how can it be considered AC?

When the developer delivers the product the designer looks at it and doesn't like the result. The designer requests N# of changes mid sprint. This is a cause of scope creep because these changes: colors, scroll behavior, font used, hover behavior etc were not captured prior to the start of the sprint.

How can this process be improved?

Answer 1

A designer delivers a mockup to a developer. That mockup is delivered as part of the story, but may or may not be considered actual acceptance criteria.

Are you saying that whether or not it is AC varies from time to time, or that there is disagreement about this between designer and developer? If the latter, this is the first thing to get clarified: you have to have a common understanding of this.

After all, the mock may not even look finished or behave correctly. So how can it be considered AC?

This smells a bit of legalistic word-chopping to me. If this is the argument you're using with the designer or with management, I wouldn't expect them to be at all convinced. Especially if the conversation happens after development, instead of when the mockup was presented. Developer & designer need to understand themselves as part of the same team, working together to make the best product, rather than against each other trying to "win" some point or other. Part of PM's job is to cultivate that teamwork.

Mockups can and should be accompanied by verbiage describing anything not on the mockup, that are intended as AC.

Because of the iterative nature of agile, AC should generally be understood as "minimum for acceptance", not "exactly how we want it", with the understanding that desired improvements can go into the backlog & be prioritized alongside everything else.

Regarding the concern in your comment above

My concern is that if [designer & developer] work together like this then a control that we estimated to be 2 points could be in fact an 8 point control depending on what the designer actually decides they want.

This again sounds like you're not nailing down agreement on scope at the beginning of the sprint. The designer, of course, has to understand what the scope is for this sprint. Emphasizing that the sprint is timeboxed may be helpful: most people understand that you can only get a finite amount of work done in a finite amount of time. You may also need to explain (and reiterate) the concept of scope creep and its risk to the project overall.

What does the accompanying story look like? Maybe taking the design mockup as AC is part of the problem. A well-written story should specify what the user (or other actor) should be able to do, not how it is done.

EG, if the story says "A user can enter text in 2 fields and choose options from 3 dropdowns", then any issues such as these

If they add scrolling, editable fields, tooltips, animations, responsive design etc after the fact then this could actually happen.

are very obvious scope creep & there should be no problem rejecting them.

Answer 2

One of the key goals of agile approaches is to speed up delivery by splitting it up into a number of small achievable tasks. But to make this happen you MUST have clear and detailed AC for each task.

This pushes a lot of work back on whomever is writing the AC. In fact in my view it makes it impossible to define tasks correctly the first time around.

The way to counter this isn't to change AC mid sprint, or to have team members 'work together' on undefined tasks. It's too keep the task small and do things incrementally.

Yes you need a design for that webpage, but don't try to make it the perfect final design. Just make it black and white with some holding text. Next iteration Add colour, Next add the text from marketing etc.

Because you can see what happens at the end of each sprint you get the chance to feed that into the design moving forward.

If you need that wheel of feedback and change to spin faster. Do shorter sprints. Don't be tempted to look at the finished tasks mid sprint and add changes. This only slows things down in the long run.

PS. I would also suggest adding more rigour to the design process to try and cut down on redesigns. Get sign off on the colour pallet, menu top or left etc. get people to justify their choices. Choose the colour which sells most units not the one the ceo likes today

Answer 3

How about this approach:

A developer and a designer sit next to each other. The designer prepares a mockup and while doing it occasionally shows it to the developer. When the mockup is done the developer starts work and frequently shows the designer how it looks. Feedback is given througout.

This isn't scope creep, it is two team members working together effectively to deliver a product.

Answer 4

New Work Isn't Allowed Into Current Iteration

When the developer delivers the product the designer looks at it and doesn't like the result. The designer requests N# of changes mid sprint. This is a cause of scope creep because these changes: colors, scroll behavior, font used, hover behavior etc were not captured prior to the start of the sprint.

Then they don't get included in the current Sprint. They become work that the Product Owner, not the designer, gets to prioritize (or not) in a future Sprint.

Agile methodologies work in iterations. Work that meets the criteria defined at the start of the Sprint or otherwise meets the Definition fo Done (DoD) is considered complete, while work that isn't specified for the Sprint or included in the DoD is considered out of scope for the current iteration.

Your Product Owner and Scrum Master, or whatever equivalent roles you've defined if you aren't using Scrum, need to enforce some rigor in your process. No one can succeed if you keep moving the cheese, so stop doing that.