, , , ,

AGILE provides various methodologies to manage your work and they can be combined to suit the project. Beauty of being AGILE, love it!

SCRUMBan, as the name clearly suggests, combination of SCRUM and Kanban is one such approach.  I’ll share why and how we used this approach to deal with production issues a while ago at work!

Why Not just SCRUM ??

  • We did not have a dedicated team.
  • We did not want to and could not define ‘tight’ scope of work in sprints or very specific time commitments were to be avoided.
  •  Reduce overhead of SCRUM ceremonies, we wanted to tailor them, be as flexible as possible!

Why not just Kanban?

  • We wanted to do planning & grooming and prioritizing. Production Issues Backlog has frequent newbies and prioritizing.
  • We wanted to have Retrospectives so we could find out our good, bad and ugly, more like a regular review. Did I say some fun too 🙂

 When can you use Scrumban?

  • On-going work with no fixed release deadlines
  • When you need to have a pull-based systems.
  • When cards are more or less independent of each other

It works well for projects/work dealing with application support and production issues  and when tasks are more or less independent of each other.

What did we do?

  • We had a separate branch for this project, which would be merged to a release branch just before regression commencement.
  • Issues were prioritized in  backlog depending on the pain they were causing to the customers.
  • The Team
    • Two developers from application support team
    • The Dev Lead, his inputs were important in terms of what can be included for this team’s work which would just require generic regression.
    • One QA
    • SCRUM Master, which was me!
  •  Team worked on issues when they had time form their routine tasks.
  • 3 weeks sprints: We chose this as 2 weeks was too short for such a project and more than 3 weeks was too long before everyone sat together to discuss the backlog
  • Sprint Planning and grooming in one meeting. Backlog was prioritized by Product Owner before the meeting. It used to be more of a grooming session to flush out enough details for cards.
  • SCRUM twice a week only. Quick huddles, if required.
  • Showcase/Demo done with other Projects, which were dealing with new features/functionality. Mostly done in the demo just before a planned release.
  • No Metrics except for related discussions in Retros. 


Meetings/Ceremonies were context driven and always served a purpose! It worked quite well for the team and the Project because we used the utmost flexibility whilst using the best of both SCRUM and Kanban.