From Scrum to Scrumban: An Agile Journey


In June of 2012, I gave a presentation to the PMI Agile Interest Group in Atlanta about my team’s journey from using the Scrum methodology to more of a Scrumban process.

Why move to scrumban?

The State of Agile Survey 2010 by VersionOne supports anecdotal evidence: Scrum is the most popular agile methodology.  It would be natural to ask why a team that started with that practice moved to Scrumban, or anything else for that matter.  Three items emerged in repeated retrospectives that led us to shift gears:
  • One of the issues was was the additional stress around completing stories on the scrum board by the last day to avoid “failure.”  Along with the pressure of solving new problems in the course of true R&D style development, the team felt pressured to (1) take shortcuts to complete work early enough, and (2) shortcut testing to close the story and claim the points.  Regardless of the percentage of stories completed by sprint’s end, we determined that the average velocity over most three-sprint periods remained roughly the same.
  • A second problem was the team spent a full day or more (out of 10) doing detailed tasking, in order to come up with estimates that led to incomplete stories and stress at the end.  We also recognized that when starting a new story mid-sprint, we’d have to revisit the initial conversations anyway, when details were invariably forgotten.  Also, based on the previous bullet, that the reliability of the projections wasn’t high to begin with.
  • A third problem was that with a group of stories to complete, each team member started on a different story at the same time, which prevented collaboration and led to lack of focus.

What was the result?

Based on all of the above, we decided to abandon the first-day tasking sessions and do the detailed planning for stories just-in-time. This means things only moved across the scrum board when action was wrapping up, not in advance of when we predicted action would tak eplace. Further, we decided to only start one story per pair, when the pair was ready to work on it.

We were no longer following the scrum methodology.

This we determined was what many call “scrumban,” a blend of the timeboxed ritual of scrum with the flow management of kanban. This meant we maintained the iteration barriers, biweekly demos, standups, and retrospectives that we conducted with scrum. Because biweekly demos kept happening, the fact that the mindset was vastly different wasn’t immediately obvious to other stakeholders, but what we stressed was meeting deliverable dates.

The team responded well to a clearly painted vision and a target date, as long as it was reasonable. The team did not respond well to being chastised for failing to complete specific stories in specific sprints which were not tied to a release. Coincidentally I spent some time with another team in Q3 of 2012 and discovered they too were struggling with some of the same problems, primarily unnecessary frustration around the inability to complete every story within artificial sprint boundaries.

Does Product Management Care about Scrum vs. Scrumban?

I argue that Product Management can manage Agile better under Scrumban than Scrum, especially when there’s a single person serving as product manager and product owner–because there’s less time-sensitivity around the product owner’s need to be present in the room with engineering.

The business still wants to know when things are going to be done–so it’s still important to ensure everything else (proper discovery, obstacle clearance, etc) is taking place to expedite timely delivery.

Here’s how it helped us:

With robust engineering practices around test-driven-development and especially behavioral-driven-development, the product owner’s information was captured during story elaboration when a feature is started.  The team thinks through all the scenarios and details one or more stories to support them, with all scenarios for each story captured in English-derived Gherkin.

RELATED:  Product Managers and Requirements Gathering

The team then gets to work and calls the product owner when the software is able to pass those specifications–and obviously, when questions come up. This process allows ample time for the product owner to engage in expectations management throughout the organization, requirements gathering, customer development, and all the other fun things a product manager is responsible for… meetings 🙂 The PO needs to be available to see stories demonstrated once they’re ready for the “Done” column – and to answer questions when they come up.

Long term, velocity also improved by 20%.  That also makes Product Management happy!


  1. Teresa Torres

    Interesting read. We experience many of the same issues you outlined. Checking out Kanban has been on my list for quite some time. Perhaps I should bump it up.

  2. Your description sounds very similar to the path we’ve been on since October. Our rationale was converse to yours where we were after the velocity increase and achieved the reduced stress around Agile semantics.

    We did start off with trying to define the stories and criteria in Gherkin for some time. We found that this artifact needed to be updated too frequently of slowed the development process down. After a couple of iterations gnashing about that we dropped it until after the feature(s) solidified more. The resulting Gherkin would be included as part of QA automation and used to document the business rules for future reference.

    In its place we use a set of high level success criteria. This helps the team identify the goal or finish line. It has been working out pretty well. The only ripple I am perceiving is the accounting. There is implicit faith in the team’s velocity but quantifying it for outsiders is tougher because points are more loosely applied. There is also a certain amount of chaos that needs to be managed because several features are all in flight and at different stages all at the same time. I can imagine how an air traffic controller feels at times.

    Thanks for sharing the slides and experience. Glad to hear others are trying similar things.

    • Interesting note, Larry. We addressed the air traffic control by (informally) instituting a WIP limit. We only start 2 items at a time, and the team rallies around each one until it’s complete. That also helps engineering and PM keep mental focus. We do struggle a bit with the accounting, especially as we continue to do a good bit of R&D where the story sizing is very imprecise. We try to mitigate by referring to t-shirt sizes but, unfortunately, we still had to assign point values to each size.

Leave a Reply

Theme by Anders Norén


Get the B2B Product Newsletter to Master Your Craft

Join over 300 product managers sharpening the saw.

%d bloggers like this:
Read previous post:
Inbound Marketing and Personal Branding at B2BCamp Atlanta

This January 19, I'm offering a Town Hall session at B2BCamp Atlanta on Inbound Marketing Techniques for Personal Branding. What's with...