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 :)
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.
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.
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.
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'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!
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:
Drive: UX practitioners are part of the customer or product owner team.
Research, model, and design up front - but only just enough.
Chunk your design work
Use parallel track development to work ahead, and follow behind.
Buy design time with complex engineering stories.
Cultivate a user validation group for use for continuous user validation.
Schedule continuous user research in a separate track from development .
发布评论
评论（7）
以下是我建议您如何做的（即我们尝试如何做的）
冲刺前 0：确保您对自己想要做的事情有一个良好的愿景。 不必非常详细，但不应该是“我们想要建立一个社交网站”
Sprint 0：开发人员工具设置 - 设置 CI 服务器，处理部署脚本等，这样所有的基本框架就完成了。 最后，您应该能够按下一个按钮（最坏的情况：在远程服务器上运行单个命令），该按钮获取源代码控制系统中的代码，构建它，打包它，运行您想要的所有测试它报告回来，如果可能的话，将其安装在测试服务器上（或者至少产生一个可以安装在测试服务器上的包）。
这个时候，设计师正在做线框图。 他们的目标是为您认为需要的尽可能多的网站制作基本线框（考虑站点地图和流程而不是字段和像素）。 然后，完成后，与 PM 一起确定最重要的事情，并详细说明这一点 - 线框图。 还不是像素。
项目经理等正在与设计师和企业/利益相关者合作，为您编写故事和任务以供执行和跟踪。 显然，他们需要了解站点地图等才能做到这一点。
这可能需要多个冲刺。 从一个开始（我建议 2-3 周的冲刺 - 1 太短，4 太长），看看你还需要做多少事情等等。
所以在冲刺 0 结束时，你有：
那么您就开始冲刺 1
请记住，对于前 3-4 个冲刺，您将不知道在冲刺中可以做多少工作，所以预计会出错！ 尽可能多地完成你认为可以完成的工作（按照业务/PM 放置的优先顺序）。 您以后可以随时服用更多！
您开发这些页面，然后设计者对下一个页面块进行线框图（由 PM 确定）。 也许设计师为这些页面做了艺术，所以你可以在下一个冲刺中完成它
所以，你正在开发你所拥有的东西，而设计师正在为你的下一个冲刺做一些东西。
当然，他们也可以进行 Scrum 流程，只是他们提前开始了冲刺！
完成工作
现在重复，直到在冲刺期间 ，如果（比如说）需求发生变化或添加新内容，然后为此编写一个新故事，并将其安排到工作中。 如果它的优先级很高，它可能会排在顶部，并成为下一个冲刺（通常是 1-2 周后）的首要项目。 或者它可能是一个很好的拥有，所以它放在底部 - 由业务决定。
PM/设计师需要知道他们可以改变一些事情，但改变确实会产生后果，所以来回改变并不符合他们的（经济）利益。 但需求确实会发生变化，XP 和 Scrum 比瀑布更好地处理这个问题。
不要忘记：
经理应该能够预测项目何时结束——看看你在上一个冲刺中做了多少工作（你的速度），然后除以这个量该数字还剩下多少工作，您就可以得到要进行的冲刺数量。 简单的。
哦，还有阅读故事点——不要在几小时或几天内估计故事。 使用积分。 为了引导这一点，只需将您估计的第一个故事（例如）设为 8（序列为 1、2、3、5、8、13、21、40、60、100、无限）。 然后拿第二个故事，相对于第一个故事进行估计——它的工作量是（13）的两倍吗？ 一半的工作（5）？ 大约相同（8）？
在冲刺结束时，将你完成的分数加起来，这就是你的速度。 您可以在下一个冲刺中承诺完成的最大工作量就是该数量。 你总是可以提前停止冲刺，或者如果你提前用完，就可以从积压的工作中拉出更多的工作等。 当你继续前进时，你的速度会稳定下来。
该死，我确信有关于如何运行它的书籍等，所以我会停下来:)
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:
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:
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 :)
我强烈不同意杰森提供的答案。 Scrum 的全部意义在于摆脱设计师首先“做他们的事情”然后继续做其他事情的方法。 这完全 100% 违背了所有精益/Scrum 原则！
将设计师纳入 Scrum 流程的方法是什么？ 把它们扔进去！ 确保您不只是将瀑布项目包装到 Scrum 中，因为这是通向失败的最佳途径！ Scrum 只有在无例外地实施时才有效。 “Scrum，但是……”是最糟糕的项目模型。 组织工作，以便可以并行设计和开发。 初始设计不要过度，而要使其成为推拉式的情况，即硬币的两面都会影响另一面。 Scrum 的要点是迭代、迭代、再迭代，因此要充分从中受益。
而且，实际上完全避开传统的基于 Photoshop 的设计是相当精简的。 您可以从信号与噪声中这篇优秀的博客文章中阅读更多相关信息：
http://www.37signals.com/svn/posts/1061 -为什么我们跳过 Photoshop
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
我以前做过这样的事情，设计师在早期迭代中完成了他们的工作，他们的工作产品被开发团队在后来的迭代中使用。 当开发团队开始工作时，设计师将继续进行项目的其他部分，或者可能进行其他项目。
您仍然可以这样做。 您的设计师可以进行更大的前期设计，开发团队可以使用 Scrum 进行迭代。
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.
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.
对于 sprint 0 中的设计部分，您可以使用 Styletyles (http://styletil.es) 等技术来确定项目所需的图形样式。 因此，您不需要预先进行大型设计，并且在冲刺时仍然保持敏捷。
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.
这很容易！ :) 好吧，让我分享一下我们是如何做到的。
第一个 Sprint
1) 产品负责人创建线框并添加到待办事项列表中（我们使用 Yodiz，www.yodiz.com）
2）我们的平面设计师创建模型并将其放在模型共享工具（www.concept.ly）上
3) 我们的开发人员致力于设置服务器。 如果一切都已经准备好，我们就有非常聪明的产品负责人，您将始终有积压的项目可供选择。
冲刺二
1) 开发人员开始研究最终确定的模型，这些模型已在概念上最终确定。
2) 设计师负责产品所有者在待办事项中添加的其他线框。
我告诉过你这很容易！
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!
我想分享一下。 我是未来社交应用开发团队的 Scrum Master。 该团队有 1 名用户界面设计师、1 名用户体验设计师（我）、1 名前端开发人员（css、ajax 等）和 3 名程序员。
这是我们第一个使用 SCRUM 框架的项目，因此非常具有挑战性。 我们的 scrum 日常会议中的趋势是，我们的设计工作从未完全完成，因为我们最初的产品待办事项列表中有诸如“用户希望被说服注册”之类的故事，然后我们在该故事上添加了“演示方式”，因此从在那里我们可以确定需要做什么（即我们需要做线框，完成文案写作等......）
可以做得更好。 根据该故事逐项列出每项任务，并估计每项任务的时间。 例如，在产品待办事项期间，我们可以从那里开始按顺序创建这些：站点地图> 任务流程> 线框图
现在的问题是，我们是否在冲刺中完成所有这些工作？ 或者我们应该在任何冲刺之前就这样做吗？ 如果我们不进行冲刺，就违背了 Scrum 的目的，对吗？
做过用户体验设计的人都会知道，这些任务需要相当多的时间来准备。 那么为什么不将所有这些都纳入冲刺呢？ 让程序员也参与这些任务。
线框图在整个项目期间非常重要。 它就像建筑物的蓝图，从头到尾都在使用。
因此，在第一个冲刺期间，根据产品待办事项列表制作初始线框图。 并在每个其他冲刺期间相应地调整线框。 我们的程序员将根据任务流程设计他们的代码，然后根据线框图直观地创建它。
哦，顺便说一句，不要太担心产品的外观（尽管拥有初始设计模型总是一件好事）。 相反，应该关注用户的需求和愿望，并设计一个非常以用户为中心的流程来实现这一目标。 我们的设计师随后会弄清楚他要设计什么样的界面。 如果线框图设计得当，设计师在设计用户界面时就不会遇到什么问题。 创建文案也是如此。
总之，在每次迭代期间携手合作。 对于初学者（像我一样），请给 SCRUM 一个为您工作的机会。 如果它适用于 fantasyinteractive.com 这样的公司，那么它对你和我有用吗:)
PS 对于伟大的线框，使用omnigraffle（mac）这就是狗屎！
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!
虽然这篇文章已经很老了，但它促使我自己研究。 我发现杰夫·帕顿（Jeff Patton）针对用户体验设计师/从业者的“十二个新兴实践”，我认为它特别适合这个问题，并且是一个非常有用的框架集：
如果您想深入了解，Jeff 会详细说明 agileproductdesign.com。
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:
if you'd like to dig deeper, jeff spells it out agileproductdesign.com.