This post comes courtesy of Greg Henderson, Senior QA Manager at Quisk HQ.
Within the agile and mobile payments community, and certainly here in Silicon Valley, both Scrum and Kanban methodologies are fairly well known. There’s a third option, however that fewer financial services companies are using: a hybrid approach combining the best elements of both in a totally new and more flexible methodology called “Scrumban”.
Scrum + Kanban
As an engineering team, we have experimented with Scrum and Kanban at various points, but Quisk’s new Scrumban methodology has now been in use for several months and has been delivering measurable product development advantages over both agile systems for our customers.
To understand what makes Scrumban at Quisk so much better — and why you may want to consider it in your own agile workflow — let’s begin by looking at some of the high-level challenges and benefits of both Kanban and Scrum. See if these align with your own experience using these methodologies:
Challenges of Kanban
· Hard to readily tell which release any given story is scheduled for
· Hard to track velocity metrics (we have been trying for some time)
· Team needs to be motivated to “pull” stories proactively
Benefits of Kanban
· No sprint after sprint burnout
· Quality not compromised because of artificial deadlines
Challenges of Scrum
· Burnout by end of every sprint for both DEV & QA
· Splitting stories upfront to fit into a sprint is tricky
· Overhead of creating Scrum boards for each sprint
Benefits of Scrum
· Perfectly aligns with the “2 week release cycle” promised to customers
· Mandatory sprint planning, standups, and grooming ensures everyone is on the same page
· Easy to track metrics — story points, burndown charts, etc.
At Quisk, we use a web-based Kanban board to apply many of the Scrum and Kanban principles. The board provides visibility to the current and next sprint stories. Remaining stories stay in the Product Backlog, which is owned by the Product Owner. There is no need to create a new Scrum Board for each sprint because the same board is used. Stories can be added to the board during Backlog Refinement and the Sprint Planning meetings.
We use the following Scrum components: Sprint Planning, Daily Scrum Standups, Product Backlog Refinement, Sprint Review (Demo), and Sprint Retrospective.
At Quisk we have been successful at maintaining a Product Backlog that is customer-driven, using Epics to drive roadmap features. Sprint Retrospectives help support continuous improvement of the team. The Daily Scrum allows the team members to give status about what work has been done and what work remains. The Product Backlog Refinement meetings have been helpful to prioritize the Product Backlog and for the Product Owner to highlight and clarify upcoming stories.
One of the main Kanban components we use is the web-based Kanban board mentioned previously, where our developers “pull” stories from the Sprint backlog. Stories move left to right on the board. Each column on the board can have a limit, which helps us understand the workload constraints.
A look at Metrics and Results
At Quisk, we measure velocity with Story Points that are sized by the developer who owns the story, the test engineer, and the DEV manager.
Story Point assignment typically occurs after discussion with the
Product Owner and at the design meetings. The points are assigned based on person-days. For example, if a story is expected to take 3-person days, the Story is given 3 points. We also create a story for bugs to fix in the sprint. Points are sized as (n* .25) and done by the Scrum Master. In other words, for every four bugs to fix we assign 1 Story Point.
We estimate effectiveness by looking at the Plan to Fix tickets vs. the Actual Fix tickets. The goal is to see how effective we are when planning what tickets to fix for a given sprint.
Bug Triage Rate is measured as the the volume of bugs ‘Found vs. Fixed’ for each sprint, as shown at right.
We also look at the SLA (Service Level Agreement), which is the average resolution time for P1 & P2 issues.
Conclusion: Scrumban as a Solution in Fintech and Mobile Payments
As mentioned, Quisk has been using Scrumban for the past several months, and we’ve tracked measurable improvements in both our productivity and our velocity. In addition, since making the change to this hybrid approach, our Scrumban team is better able to manage the Sprint Backlog and “pull” work into an easy to manage Work in Progress (WIP) queue.
Most importantly for Quisk as a mobile payments company, using Scrumban we are better able to plan and deliver high-quality features to our customers.
As anyone who has closed a sprint can attest, there is nothing more rewarding than seeing how much we have achieved as a team. During Sprint Demos the engineering team can collectively share features and benefit from both a confidence in our product and an understanding that we are releasing improvements that make a real difference to our customers. This is coupled with a Sprint Retrospective, which brings us all back to earth a bit, examines opportunities to improve, and looks at some start, stop, and continue actions to implement during the next sprint.
At the end of the day, identifying and prioritizing efforts most relevant to the open payment capabilities we want to improve is what any of these methodologies are all about. If more flexibility is needed to achieve this consistently and effectively, we encourage you to take a look at a Scrumban implementation.
If you have any questions or comments on scrumban at Quisk, or thoughts about how to improve this agile flow in your own organization, drop us a note in the comments section or reach out to our technology team on twitter @GetQuisk or via email at email@example.com
We’d love to hear from you.