How do you apply Scrum to the design part of web development?
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?")
Answer
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 :)