How do you apply Scrum to the design part of web development? [closed]

Question

I'm starting to learn about Scrum, and I'm interested in trying it out with our development team. I have a lot of questions about it...but my biggest mental roadblock is in the actual graphical design.

With our current development cycle [waterfall-esque], our graphical designer lays out the page with all the imagery and such based on a loose PRD. If we were to utilize the methods of Scrum, how would this development take place? I think we're used to seeing the big picture and driving towards it...as opposed to fitting the visual pieces together as we go, which is what I'd expect the Scrum policy for graphical design to be.

Would it be unheard of to at least wireframe all the functionality in the backlog? Or would it be wiser to--for the first sprint--design its functionality in such a way that we can add the new features of other sprints as we go? (i.e. When it's time for a new feature, discuss "Where would this fit into the current design?")

Aldine

I think this question may be off-topic because it should be at programmers.stackexchange.com – Dugger

Answer 1

here's how I'd suggest you do it (ie, how we have tried to do it)

Pre-sprint 0: make sure you have a good vision of what you want to do. Doesn't have to be super detailed, but should not be "we want to build a website which is social"

Sprint 0: Developers tool up - setup the CI servers, work on the deployment scripts etc, so all the basic framework is done. At the end of this, you should be able to push a button (worst case: run a single command on a REMOTE server) which takes the code in your source control system, builds it, packages it, runs all the tests you want on it, reports that back, and if possible, installs it on a test server (or atleast results in a package you can install on the test server).

At this time, the designer is doing the wireframes. Their aim is to do basic wireframes for as much of the site as you think you need (think sitemap and flow not fields and pixels). Then, when thats done, work out with the PM's whats most important, and go into detail on that - wireframe. Not pixels YET.

Project managers and the like are working with the designer and the business/stakeholder, writing up stories and tasks for you lot to do and track. Obviously, they need to have an idea of the sitemap etc to do this.

This may take more than one sprint. start with one (I recommend 2-3 week sprints - 1 is too short, 4 is too long), see how much you still need to do etc.

So at the end of sprint 0, you have:

• Lots of stories, in priority order (you CAN add more later, infact you will always as requirements change)
• A sitemap (ie, a general idea of what the whole thing is going to contain)
• Wireframes for the first block of work
• All your tools are working and setup
• You CI, bug tracking, source control and deployment systems are in place

So then you begin sprint 1

Keep in mind that for the first 3-4 sprints, you will not know how much work you can do in the sprint, so EXPECT to get it wrong! Take off as much work (in the priority order the business/PM has put them in) as you think you can FOR SURE get done. you can always take more later!

You lot develop those pages, and the designer(s) wireframe up the next block of pages (as determined by the PM's). Maybe the designer does the art for those pages, so you can do it in the next sprint

So, you are developing what you have, and the designers are working on stuff for your next sprint.

Of course, they could have a scrum process going too, just they started a sprint earlier!

now repeat until you run out of work

during a sprint, if (say) a requirement changes or something new is added, then a new story is written for that, and it's scheduled into the work. If it's super high priority, it may go at the top and be the top item for the next sprint (which will be 1-2 weeks away, usually). Or it may be a nice to have, so it goes at the bottom - the business decides.

PM's/designers need to know they can change things, but changes DO have consequences, so it's not in their (financial) interest to chop and change back and forward. but requirements DO change, and XP and Scrum deal with this better than waterfall.

Dont forget:

• you can stop a sprint at any time and go back to planning, eg if the requirements change too much, or you run out of work
• you can schedule more work than you have time to do, as long as that work hasn't been committed to (ie, it's "extra" or "stretch" work)

Your PM should be able to predict when the project will end - look at how much work you did in the last sprint (your velocity), and divide the amount of work left by that number, and you get the number of sprints to go. Easy.

Oh, and read up on story points - dont estimate stories in hours or days. Use points. To bootstrap that, just make the first story you estimate (say) an 8 (the sequence is 1,2,3,5,8,13,21,40,60,100,infinite). Then take the second story, and estimate it relative to the first - is it double the work (13)? half the work (5)? about the same (8)?

At the end of the sprint, add up how many points you did, and that's your velocity. The max amount of work you can COMMIT to do doing in the next sprint is that amount. You CAN always stop the sprint early, or just pull more work off the backlog etc if you run out early. As you go along, your velocity will stabalize.

Damn, I'm sure there are books etc on how to run it, so I'll stop :)

Pannikin

+1 "Damn, I'm sure there are books etc on how to run it, so I'll stop :)" nono - keep going :) – Malicious

Where did you get the sequence (1,2,3,5,8,13,21,40,60,100,infinite)? – Hibachi

Or more specifically, what benefit does one get by estimating using the Fibonacci sequence? – Hibachi

Each one is a little under double of the previous one. It's easier to estimate that job A is double, half, or the same size as a previously estimated one. – Pannikin

Answer 2

I strongly disagree with the answer provided by Jason. The whole point of Scrum is to get rid of the method where designers first "do their thing" and then go on to other stuff. That's completely and 100% against all lean / Scrum principles!

The way to incorporate designers in a Scrum process? Throw 'em into the mix! Make sure you're not just wrapping a waterfall project into Scrum as that's the best way towards failure! Scrum only works when it's implemented without exceptions. "Scrum, but..." is the worst project model. Organize work so that it's possible for concurrent designing and developing. Don't overdo initial design, but make it a push-pull situation, where both sides of the coin influence the other. The point of Scrum is to iterate, iterate and iterate, so take full benefit from that.

Also, it's pretty lean to actually shun traditional Photoshop-based design altogether. You can read more about this from this excellent blog post in Signal vs. Noise: http://www.37signals.com/svn/posts/1061-why-we-skip-photoshop

Dichlorodifluoromethane

Hi. I guess this is an old discussion, but it is relevant to me, so I'd like to ask something here. I see how designers can provide a high level designs within a particular sprint. But when will these be refined (made production read)? Will it not be too much work to go back and fix the designs as whatever was done before did not exactly fit into the bigger picture (e.g. styling was not consistent, etc...) – Unprincipled

Actually after this discussion I managed a pretty intense Scrum-based project that had a lot of design involved and we tackled the design / implementation synchronization issue by having two intertwined Scrums in parallel: design project and implementation project. In very broad terms, when the coders were implementing sprint N, the designers were building sprint N+1. All still in the same space, so the instant feedback loop was there. Obviously there was a lot more details involved, but this was the baseline. I think that worked really well. – Otto

I have first hand experience with both of these practices and trust me if you want precise and painless sprints try to get as much as you can from system analysts and UI/.Ux designers before the sprint starts. Imagine picking a feature to work on and not knowing its exact design requiremnts and business rules. This puts your team at risk of handoffs and partially done works. – Intrusive

Answer 3

I've done this before where the Designers did their thing in the early iterations, and their work product was used by the dev team in later iterations. As the dev team started work, the designers would move ahead to other parts of the project, or possibly to other projects.

I think we're used to seeing the big picture and driving towards it

You can still do this. Your designers can do a bigger up-front design, and the dev team can use Scrum to iterate towards that.

Willey

Answer 4

For the the design part in sprint 0 you can use a technique like Styletyles (http://styletil.es) to determine the graphical style needed for the project. So you dont need a big design upfront and still be agile when you are sprinting.

Yvor

Answer 5

It's easy peasy! :) Well, let me share how do we do it.

First Sprint

1) Product owner creates wire-frames and add to backlog (we use Yodiz, www.yodiz.com) 2) Our graphic designer create mockups and put them on mockup sharing tool (www.concept.ly) 3) Our developers work on setting up servers. If everything is already ready we have pretty smart Product owner, you will always have items in backlog to select.

Sprint Two

1) Developer start working on the finalized mockups, which were finalized on conceptly. 2) Designer work on other wire-frame added by product owner in backlog.

I told you it's easy!

Gorgonzola

Answer 6

I'd like to share . I'm the scrum master for a development team of a future social app. This team has in it 1 User Interface designer, 1 User Experience designer(me), 1 front end developer(css,ajax etc), and 3 programmers.

This is our first ever project using a SCRUM framework so it's been quite challenging. The trend during our scrum daily meetings is that our design work are never quite done done because our initial product backlog had stories like 'User wants to be persuaded to sign up' and then we added on that story a 'way to demo' so from there we could determine what needs to be done (i.e. we need to do wireframe, have copywriting done, etc...)

That, could be done better. Itemize every task based on that story, and estimate time for each task. For example, during product backlog, we could from there on create these in order: Site Maps > Task Flows > Wireframes

Now the question is, do we do all these in a sprint? Or should we do this even before any sprint? Defeats the purpose of scrum if we do out of sprints right?

Those who have done user experience design will know that these tasks take quite an amount of time to prepare. So why not make all these part of a sprint as well? Get programmers involved in these tasks as well.

Wireframing is very very important throughout the duration of the project. It's like the blueprint to a building, where its used from start to finish.

So, do an initial wireframe based on the product backlog during your first sprint. And adjust the wireframe accordingly during every other sprint. Our programmers will design their code based on the task flow and then create it visually based on the wireframe.

Oh, btw, dont bother too much about how the product is going to look like (tho having an intial design mockup is always a good thing). Instead, focus on the user needs and wants, and design a very user-centric flow to achieve just that. Our Designer later then figures out what kind of interface he is going to devise. If the wireframe was done proper, the designer will have very few problems designing the user interface. Same goes for creating copywriting.

In summary, work hand in hand during every iteration. For beginners out there (like me) give SCRUM a chance to work for you. If it can work for companies like fantasyinteractive.com , so can it work for you n me :)

p.s. for great wireframes, use omnigraffle (mac) tis the shite!

Aesthetics

Answer 7

If we were to utilize the methods of Scrum, how would this development take place?

while this post is quite old, it prompted me to research on my own. i found Jeff Patton's "Twelve emerging practices" for UX designers/practitioners, which i thought to be apt to this question specifically, and quite a useful frame set:

1. Drive: UX practitioners are part of the customer or product owner team.
2. Research, model, and design up front - but only just enough.
3. Chunk your design work
4. Use parallel track development to work ahead, and follow behind.
5. Buy design time with complex engineering stories.
6. Cultivate a user validation group for use for continuous user validation.
7. Schedule continuous user research in a separate track from development .
8. Leverage user time for multiple activities.
9. Use RITE to iterate UI before development.
10. Prototype in low fidelity.
11. Treat prototype as specification.
12. Become a design facilitator.

if you'd like to dig deeper, jeff spells it out agileproductdesign.com.

Kathyrnkati