Layout comprehensives in an agile process

Pictures may be worth a 1,000 words, but don't assume they are the right ones

Posted by Tejus Parikh on June 9, 2020

When you peel back the covers on most agile software teams you’ll often find a collection of processes that are more accurately modeled by a waterfall. Comprehensive layouts (“comps”) created by design teams to often put a hard stop to any true agile process. Comprehensives look like an application. This is doubly true with modern mock-up tools that can simulate user flow. So when it comes time to evaluate the output of the engineering team, there is a natural inclination to compare the live application to the comp and determine success based on how closely they match. This is not agile.

A true agile process is built on user stories that describe the need the user has from the system. A user story is complete when the acceptance criteria has been met. Agile organizations utilize user stories in lieu of business requirement documents that seek do describe every facet of a feature in detail which forms the top of the waterfall in traditional organizations. Agile replaces pre-planning with iteration and constant evaluation of delivered, functional product which feeds into the next phase of creation.

When the success criteria of a project is how closely it matches the comps, the comps essentially become the requirement document the agile process sought to avoid. Everything else follows down stream. Engineers start breaking down stories based on the visuals and QA opens bugs when they don’t match. Acceptance criteria that is not represented visually drops off the radar and the user story as a whole runs the risk of being neglected. Agile was intended to facilitate quick iteration, but now every change or customer request has to start at the top and trickle down, thereby lengthening cycles.

While this happens often, it does not have to be this way and comps can be a valuable artifact in an agile process.

The most crucial element is to keep focus on the user story and the acceptance criteria, since really that’s the goal. What matters to the user is that the problem is solved in a way that doesn’t add more work for them. In that way comps are great communication tools, by aligning both the user and the engineers on how that looks and getting early feedback. If the feedback can be handled with a few notes and annotations there’s no reason for updated designs. Just build and get it into the hands of the customers for final validation.

The often ignored aspect of agile is that the process replaces upfront communication and defined contracts with constant communication and shifting interfaces. Like written requirements and, in many cases, the code, design comprehensives are another stage in the process. To treat them as an end does the whole team and ultimately, the customers, a disservice through wasted time and slower delivery.

Photo by Hal Gatewood on Unsplash

Original image is CC-licensed [original source]

Tejus Parikh

I'm a software engineer that writes occasionally about building software, software culture, and tech adjacent hobbies. If you want to get in touch, send me an email at [my_first_name]