📋
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
  2. Implementing Scrumban

Common work across teams

TechWell Hub Community

Case Study:

Hello all, I started working with a few teams. Each team has their own Scrum board and they also have a common Kanban board with high level epics for work that can be potentially be shared across teams (tools upgrades, foundational items) or that does not clearly align to a particular team. They were having issues visualizing this work at the team level - the Kanban board was use more like a list of non-functional items with a dozen or so in progress. Any suggestions on how to better handle common work across multiple teams?

Recommendation 1:

There's no one simple answer for this one, and I cannot help but wonder if some shift in approach might be useful. I mention this because the boards are really useful to track work load in a simple manner for teams. By having a situation like you mention, it seems to imply that people's work is listed in multiple places, making it harder to understand whether they are overloaded.As an example, maybe instead of a common kanban board, simply put up a poster on the wall of teams:

  • make sure to include tasks to upgrade your tools

  • make sure to consider the non-functionals - performance, security

  • etc....

it's all about quality at the end of the day. Maybe putting pressure from the other end could help - for example, if you find a slew of security or performance defects across teams, simply list the pool of defects, which become something for each individual team on their own to begin accounting for.

-- Byron Katz, Senior Technical Consultant

Recommendation 2:

In my experience with several teams in the same and different projects (all at the same time) is to have one Sprint backlog for the whole Product divided by Scrum teams. That helps everyone, including the PO having a big picture.

-- Patricia Ayuso

Recommendation 3:

I have had similar challenges in the past. So you entire team can see what's happening, I would suggest an old school approach: a big, open wall or white board, and stickies, in 4 sections (backlog/todo/doing/done) and make a large kanban with all of your tasks. Have the team members write their user stories on stickies, put them into the backlog, then move them. When you have your stand-ups, do it at the kanban board, so it becomes a living representation of what your teams are doing. You can also break the kanban into swim lanes for each epic or product. be sure everyone puts their name onto a stickie. You could also do this in Jira, but starting out on a wall with stickies during the standup gets everyone involved. The teams should be the ones doing the writing and sticky moving, though. So they realize they are involved and responsible for their work and moving it to done. Gamify it if possible.

-- Lynda Montanez

PreviousBreakdown TaskNextSustainable QA process in the organization

Last updated 4 years ago

Was this helpful?