Agile Smackdown: Scrum vs. Kanban vs. Scrumban
Description
A detailed, three-panel infographic with a hand-drawn, sketchy aesthetic comparing 'SCRUM', 'KANBAN', and 'SCRUMBAN' methodologies. Each column breaks down the framework by key attributes: PLANNING, ESTIMATIONS OF TIME, CHANGES TO WORK SCOPE, ROLES, MEETINGS, OWNERSHIP, WHEN TO USE, and BOARDS / ARTIFACTS. Scrum is depicted with structured sprints, required estimations, and defined roles like Scrum Master and Product Owner. Kanban is shown as a continuous flow system with optional estimations, WIP limits, and flexible roles. Scrumban is presented as a hybrid, combining Scrum's ceremonies with Kanban's flow and WIP limits. This educational chart serves as a visual guide for development teams to understand the nuances of these popular Agile frameworks and choose the one that best fits their workflow, project type, and team structure, moving from a highly structured process to a more fluid one
Comments
7Comment deleted
My team's methodology is simple. We do 'Scrumbanfall': two-week sprints to plan the waterfall, daily stand-ups to report no progress, and a WIP limit of one ticket that's been blocked for three months
Every team swears their board is Kanban - right up until the PM asks for story-points and a burndown chart, at which point Scrumban quietly sneaks into production like an un-reviewed hotfix on Friday
Scrumban: when you've given up on actually fixing your process and decided to name your chaos instead
The real difference between Scrum and Kanban? Scrum teams spend two weeks estimating work in story points using planning poker, then discover on day 13 that the API they needed was deprecated. Kanban teams just pull the next ticket and discover it immediately. Scrumban teams get the worst of both worlds: they still have daily standups, but now nobody knows when anything will actually ship because 'it depends on defined roles and necessities.' At least the burndown chart looks pretty until someone adds that one 'small' feature request that turns your boulder into an avalanche
We started with Scrum for commitments, added Kanban for flow, and ended with Scrumban - now we have standups, WIP limits, a burndown and a CFD, yet our real WIP limit is 37 upstream dependencies
Scrum minimizes uncertainty with ceremonies, Kanban with WIP limits; Scrumban minimizes it by making management think both metrics are green while the team quietly routes everything through the expedite lane
Scrumban: the architectural compromise where you inherit Scrum's sprint dogma but cap WIP like a sane architect - peak enterprise delusion