2

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?

1
4

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.

3
  • I'm saying sometimes the mockups are reliable (look and feel is close, but still there are the scope creep issues I mentioned), other times we have wireframes. Point taken regarding developer and designer working together. The designers tend to rely on developers "referencing" or how I feel is "reverse engineering" the legacy system in order to determine what the style should really look like as opposed to relying on the mockup. However, in reverse engineering the system the designers tend to take the result and tack on whatever they feel like in the middle of the sprint. – P.Brian.Mackey Jun 25 '16 at 22:14
  • My ultimate point is the end result that "gains done acceptance" at the end of the sprint is not close to the mockup. – P.Brian.Mackey Jun 25 '16 at 22:20
  • 3
    The mockup issue sounds like a symptom, where the causes are A) poor embrace of the iterative nature of agile, and B) lack of agreement on scope and correspondingly limited AC at sprint start. A will help you with B, and once you have B, you can control scope creep by pointing at it, & reminding everyone of the benefits of iterative development w/ real user testing between iterations. – Vicki Laidler Jun 26 '16 at 0:44
3

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

1

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.

6
  • My concern is that if we 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. If they add scrolling, editable fields, tooltips, animations, responsive design etc after the fact then this could actually happen. – P.Brian.Mackey Jun 25 '16 at 19:47
  • 2
    What is your team's definition of done? If it includes responsive design, tooltips, etc. then they should be a part of your estimates and a part of development. Sit down with the team and agree on the standard you are working to. If different members of the team have a different definition of done they you will inevitably get conflict. – Barnaby Golden Jun 25 '16 at 19:57
  • 1
    DoD includes nothing about design. Ok, I see that is a problem. – P.Brian.Mackey Jun 25 '16 at 20:01
  • 1
    Also, shouldn't the designer be including some of this in a spec? Hey here is a mockup use this font, have this padding, use this color here etc...IF they did this we could point better as developers. Cause we would know what they really were asking for. – P.Brian.Mackey Jun 25 '16 at 20:04
  • 1
    Do you have retrospectives? That is a perfect topic to raise at them if you do! – Barnaby Golden Jun 26 '16 at 8:28
0

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.

2
  • This is what I've been saying as the scrum master. However, now they are playing games. Management has found a team with a Unicorn developer that is able to figure out all these design problems and crank out code fast despite the pretty horrific mockups. Now they are cherry picking this person as a baseline for all other teams to follow. – P.Brian.Mackey Jun 25 '16 at 20:08
  • 1
    @P.Brian.Mackey Then you have a political problem as well as a problem with your Scrum process. Always solve for the real underlying problem, not the surface issues. If you can't fix the political problem, you may want to consider dusting off your resume and looking for a job that isn't destined for an epic fail. – Todd A. Jacobs Jun 25 '16 at 20:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.