I’ve been thinking a lot about how to better map the creative process to scrum. I know there are a bunch of good books out there that cover this topic, but, after reading them, I still am not clear what to do next.

In the effort to keep this super simple (and to give the creative folks as much latitude as possible within my outlines), I’m giving the above process a try with several of my teams.

It adds up to 4 simple phases, the first two of which float above and are not constrained by the sprint cadence, while the remaining two are constrained by the sprint cadence, and are specifically planned for and committed to.

1. Inception. This is the ‘blue sky’ phase where the team (creative and any other folks who want to be involved) think big, create mood boards, silly sketches, interpretive dance, whatever. Usually starts with some kind of Creative Brief created by the Product Owner, and ends with some kind of Creative Approach doc created by the whole team and approved by execs or business stakeholders.

2. Prototype/Test/Design: This is where the user interaction model is defined and tested with real users, then the overall design style guide is defined and approved.

3. Batch Asset Development: This is the first phase that needs to be planned in sprint planning. Only enough assets to fill the pipe for the following spring need be created. The team should, of course, start with the most important assets; usually home pages and key landing pages. Though un-Scrum like, I highly recommend the designer or scrum master create an asset grid in Excel that shows what goes where, who needs to see what, and what will be finished when.

4. Review. This phase includes all types of final review before the product goes live: Both page reviews by the creative person together with the developers, as well as the Product Owner, Executives, and, if possible, a final user review. This phase often happens one sprint after the developer builds the page, but the optimal approach is to be sure the review and development happen concurrently within the sprint and end with a finished set of approved pages by sprint’s end.

The key to moving this fast is to prototype. Whatever tool the designers and copy writers use should allow for annotations, live testing, and be detailed and instructive enough for the developers to see pixel-perfect pages with specific interactions to guide them (i.e., no long functional spec documents).

I’m probably dreaming this simple process will work. But for us, so far, so good.