📋
QASpace-CaseStudies
  • Home
  • Test Strategy
    • Vision of Quality
      • Good Test Coverage
      • ISO 29119 Certification
      • Date Internationalization Format
      • Localization Testing
      • Test Management
      • Creating TestCase
  • How to Test
    • How to write good TestCase?
      • Tips on Testing
      • Pair Testing
      • UserStory to TestCases
      • Optimising the development flow in a Scrum team
      • Rate/Prioritise bug tickets
  • Exploratory Testing
    • Exploratory Testing
      • Creating Test Charters
      • Test Charters
      • Velocity was too high
  • Agile
    • Implementing Scrumban
      • Breakdown Task
      • Common work across teams
      • Sustainable QA process in the organization
  • Philosophy of Testing
    • Brainstorming
  • Metrics
    • Risk Analysis
      • Testing Outsource
      • How to measure Quality?
  • Automation
    • AI-Automation
      • Software through the lens of AI
      • SAP/Salesforce Automation
      • Mobile Automation
      • Solve by automating the GUI?
      • Improve Skill-sets
      • Coding Skills
      • Working in BDD
      • Value of Test Automation
      • UI/API automation asset
      • TDD VS BDD
      • Selenium vs Cypress
      • An important consideration of Test Automation journey
      • Balance Test Automation Development
      • Automation is no longer providing value
      • Define AI in test automation
      • Unique Locators
      • Best Practices as QA, QA Lead, and Automation Engineer
      • Making friends with Imposters
  • Survey/Polls
    • Is QA really a Gatekeeper?
  • Performance
    • Performance Testing
      • Client-Side Performace
Powered by GitBook
On this page

Was this helpful?

  1. Agile

Implementing Scrumban

TechWell Hub Community

Case Study:

Can anyone share their experience and implementing Scrumban to their org? Trying to understand if there is any specific strategies besides scrum+kanban that Scrumban recommends? Want to some suggestions along with notes/sites to refer to apply that framework to our new platform.

Recommendation 1:

In my experience, most Scrumban comes from Scrum teams that add WIP limits to their Sprint board so they can focus on getting the highest priorities done before starting other work. It is often on the way for the team to move toward Continuous Delivery, meaning a more flexible release schedule so they can release more often than at the end of a sprint.

Certainly not following the Scrum cadence. Don't get me wrong, Scrum has a lot of value for the right circumstance but like any tool it has to fit the job. I would say the same of Kanban, great value for a specific circumstance.

Fair and I can see that being true for some projects. I still find in some places planning from a business perspective to be needed and often find that if the business is planning out for 3 months the dev teams want to know that plan. Generally that means an overview for a few hours a quarter and not a 1-week release planning session.

Given multiple levels of planning, I can see 3 month plans being little more than goals of ideas for goals in the future with more detailed planning with specific decisions being on a few day horizon basis. Certainly our experience can be different but I don't see many businesses that don't have big idea plans out months or longer. I do see making those immutable or in detail a problem. Meaning I see a lot of value in adjusting by what you learn and even adjusting longer term goals based on what you learn in your daily work. I do like describing your work as experiments. That can put learning in perspective.

-- Tom Steihm

Recommendation 2:

In fact, I have not experienced a team that is doing CD that is using Scrum. They all move to Kanban as so many of the Sprint ceremonies are not relevant when you are deploying many times each day.

We found that release planning, sprint planning, demo, etc. not relevant. In CD things tend to be a lot more JIT.

In my experience planning out for 3 months seems counter to the way I’ve worked in CD. My experience is that the business specifies outcomes they hope to achieve and then the product owner with the team come up with a hypothesis about how to achieve the outcomes or some aspect of the outcome. Then experiments are run and the data collected from the experiments help inform they next set of experiments. In this mode, we really do not plan beyond the next few days and constantly make adjustments based on what we learn.

-- cheezy

PreviousVelocity was too highNextBreakdown Task

Last updated 4 years ago

Was this helpful?