Scrum + Kanban = Scrumban

Scrum principles

  • User stories are individual items of work. They consist of a brief narrative from the end user’s perspective describing a piece of functionality in terms of who it’s for (could be a type of user or a scenario in which the functionality is needed), what it’s supposed to do, and the user’s end goal or real reason for wanting it. Example: “As a ____, I want ____ so that ____.” It should also include acceptance criteria and a time estimate.
  • The product backlog is the prioritized list of user stories that need to be worked on.
  • Each Scrum team consists of a small number of developers (say, 5-7), the product owner who manages the backlog and is responsible for communicating user needs to developers, and a Scrum master, the process expert who oversees the execution of this methodology. These should all be different people.
  • Work is done in sprints which are 1-2 week periods (ideally) in which the sprint backlog (a specific list of work items chosen from the product backlog) is to be delivered. The time estimates on each work item enable generation of burndown charts which allow the team’s velocity to be calculated and projected — that is, how quickly work is being done and whether all the items on the sprint backlog are likely to be completed within the sprint.
    • Each sprint begins with a sprint planning session which defines the work to be delivered based on what the team can commit to and doles out specific items to specific developers. This may involve determining the story points assigned to each user story (aka “planning poker“). Story points are a way of estimating how long each task will take, based on a relative metric rather than an absolute one like the number of hours.
    • Stakeholders outside the team may attend. With few exceptions, new work items that may arise after this point must wait until the next sprint.
    • Each day begins with a daily scrum or standup which is a brief team meeting where (1) each developer’s work items/goals are set for that day, (2) any hangups encountered the previous day are addressed, and (3) coordination needs are discussed among the team.
    • At the end of each sprint, there is a review and retrospective which is a meeting where the team discusses the work that was done as well as the “went well / needs improvement” points that the sprint revealed. Other stakeholders may attend the review to observe a demonstration of new features.
  • Each sprint results in an incremental release defined by the work items that were accomplished. Uncompleted items are returned to the product backlog.

Benefits

  • Frequent, well-defined releases
  • Transparency within the team
  • Ability to quickly adapt to changing needs
  • Enhanced focus due to limiting the scope of work being done at any one time

Drawbacks

  • Time spent in meetings that could be spent on actual development
  • Somewhat rigid

Kanban differences

  • The team may have an Agile Coach to guide the process, or they may not.
  • There are no sprints as the process is continuous. This means there are no sprint planning sessions or sprint backlogs, so the product backlog is the only backlog.
  • Work items probably don’t have time estimates.
  • The kanban board is a mandatory form of visualization and consists of columns for To Do, Dev, and Done, and is based on the idea of a “pull” system where an empty, or nearly empty, column triggers items to be pulled from the previous column.
  • Releases happen whenever items are ready, resulting in 2-3x more frequent releases.

Advantages over Scrum

  • More frequent releases
  • Less time spent on meetings

Disadvantages

  • Less effective transition from backlog to dev
  • No hard limit on WIP which causes a lack of focus (cost of context switching) and slows progress of individual items

Hybridizing Scrum using the best of kanban and Lean

Goals

  • More frequent releases
  • More time spent on work vs. meetings
  • Improved movement across the board from backlog to done
  • More flexibility

Steps

  • Instead of scheduling planning sessions, trigger them when the release backlog gets below a certain number of items. These planning sessions are to be more brief; no “planning poker”, no story points, only prioritization.
  • Stop estimating. Yes, this does mean that you will not calculate velocity by story points per sprint since we no longer have either of those, and you will not track burndowns. Another way to track it is by work items per week, month, or quarter.
  • Work items should be broken down into the smallest manageable chunks that make sense.
  • Only work items that are 100% ready for development make it into the release backlog.
  • Urgent issues don’t have to wait for the next planning session and thus can be thrown into the backlog at will.
  • Stop assigning backlog items to specific people; instead, allow people to pull items from the top of the prioritized backlog into WIP, taking the assignments on their own, thus the highest priority items are assured to be done first.
  • Set strict WIP limits to enable the pull system — one item per developer with the ability to add a second one only when absolutely necessary.
  • Add buffer columns between process stages (i.e. instead of one “In Dev” column, it would add an adjacent “Done” column which the next column can easily “pull” from).
  • Don’t move items to the left without a really good reason.
  • Don’t be afraid to break out of task assignments if it would be helpful for multiple people to attack a task together in order to get it moving to the next column.
  • Truly blocked items can be tracked separately from active items, thus not contributing to WIP limits.
  • When the release backlog is slimming down such that another planning session is imminent, a feature freeze can be imposed, preventing new items from entering the WIP column. At the same time, this can trigger a triage where all WIP items are reviewed to determined which of them will and will not be prioritized for completion as part of the upcoming release.
  • Implement long-term planning using 3 buckets:
    • The 1-year bucket is dedicated for long-term goals that the company has, like penetrating a new market, releasing new product, etc.
    • When the company decides to move forward with a plan, it is moved to the 6-month bucket, where the main requirements of this plan are crystallized.
    • When a company is ready to start implementing the plan, the requirements are moved into the 3-month bucket and divided into clear tasks to be completed by the project team. It is from this bucket that the team draws tasks during their on-demand planning meeting and starts working on the tasks.