Essentially in Scrumban we employ Kanban's ‘pull’ approach rather than Scrum’s ‘push’ approach while using theScrum principles with some modifications. So core principles of Scrumban translates to
Sprint – In a Sprint instead of limiting it as time–boxed, team ‘pulls’ prioritized ‘just in time’ (JIT) work items in the Sprint based on team's bandwidth. In other words, Sprint is ‘limiting the WIP’ instead of time-boxing the Sprint
Sprint Planning - In the Sprint Planning, team plans for JIT work items. Since Sprint is not time-boxed, team does not necessarily spend time on doing estimations but rather focus on understanding the work item goals, dependencies and how to do the work
Daily Scrum – Team continues with Daily Scrums answering basic 3 questions
Sprint Review – Team uses Sprint Review for showing demo of work items to the concerned stakeholders &
Sprint Retrospection – Team uses Sprint Retrospection for doing retrospection, providing an opportunity for continuous improvement. Ceremony can be used for identifying bottlenecks and opportunity for optimizing the work flows. In my earlier post 'Metrics For Maximizing Productivity In Kanban SDLC’, I had shared on how to maximize productivity in Kanban SDLC
Where Scrum Falls Short?
Scrum falls short when team spends too much time upfront in doing Sprint Planning and in the middle of the Sprint, there is a priority change for one or more User Stories. In some situations, an entire Sprint could be cancelled by the Product Owner or the Management for various reasons including budget constraints, change in priorities or the work items in Sprint are allocated to another project team. All this not only impacts team’s productivity but also at times the morale of the team. Another concern commonly heard in Scrum Retrospections is that the velocity is not helping do accurate estimations or the Sprint backlog is not achieving desired forecasting. Lastly, in my experience I have seen some teams following Scrum fixated on following the “process" rather than focusing on delivering value.
How Scrumban Come To The Rescue?
Since Scrumban is based on the lean principle of focusing JIT work items, team remains committed to the WIP. Scrumban provides the flexibility of prioritizing and reprioritizing work items and since team is not doing any heavy lifting of upfront planning, they remain focused on delivering value faster. Scrumban also provides the flexibility to the team for switching gears to work on expedite work items which is not possible in Scrum especially when in the middle of a Sprint without causing some serious feathers to ruffle. Lastly, since Scrumban is based on Lean values, it focuses less on following the ‘how of the process’ and focuses more on delivering the value through continuous improvement.
In summary, Scrumban is a lightweight SDLC process that combines Scrum to be more Lean & Flow oriented. In Scrumban, team achieves optimized productivity by remaining focused on JIT work items and faster cycle times. Team gets better at spending less time in doing deep dive up front estimations and instead uses more cycle-time based forecasting, which provides team with more time in actually delivering quality work item.
I will be sharing case studies, process improvements and best practices specific for Scrumban in my future posts. Meanwhile let us know if you have any questions or comments. For any questions, please reach out to me at firstname.lastname@example.org