Scrum-ban是一个Scrum和Kanban的开发模型。Scrum-ban尤其适合于那些维护的项目或者经常会有用户故事变更或程序错误的项目和系统。在这些项目中，Scrum模型中规定时间的sprint显然就不能够满足项目的需求了，但是Scrum中的每日站会和其他一些工程实践还是可能根据团队的情况加以运用。可视化的工作进度和对未完成的并行用户故事和任务的限制都是Kanban的法宝，通过这两样法宝，能够指引团队以最少的时间完成用户故事和修复程序错误以及保证团队每个成员都能持续地投入到工作中。
为了能够清楚地展示工作的每个阶段，在同一个地方工作的团队通常会使用便签纸或者一块大的白板。而分布式团队通常会使用工具软件，如Assembla，ScrumWorks或者安装上GreenHopper的JIRA来帮助团队更好地了解各个用户故事、缺陷和任务所处的状态。
最简单的办法就是把任务或者用户故事划分成以下三类：
候选
进行中
已完成
如果有需要的话，团队可能添加更多的状态，例如，“已定义”，“完成设计”，“完成测试”或者“已交付”等等。划分更细的状态能够帮助团队在遇到瓶颈又不能改变并行任务的最大限制的时候更有效地解决问题。同时，更具体的任务状态划分也能够使团队成员更专注在特定的工作环节上。
对于最大并行未完成工作的数量并没有一个通用的值，每个团队需要根据自身的情况来设定。如果这个值设得太小，有可能会导致很多团队成员有太多的时间在空闲状态；如果这个值设得太大，那么就有可能会在同一时间出现大量的未完成的工作，从而导致每个任务完成的时间大幅上升。这里给出的建议是，每个团队成员同一时间不能进行超过两个任务，另一方面在同一时间所有团队成员不能都有两个任务。
Scrum和Kanban最大的不同就是，Scrum把工作划分成固定长度的周期——sprint中，而Kanban则以持续工作的方式进行。从表示任务状态的表格来看，Scrum会在每个spirnt把表格清空，而Kanban则一直沿用同一个表格。从团队组成来看，Scrum强调的是跨职能团队，团队成员需要是多面手，而Kanban则更强调专职团队。
由于Scrum-ban是新的开发模型，因此并没有太多的参考资料。就目前来看，Kanban至少已经被Microsoft和Corbis采用了。
