Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Kanban - with Minions.

Kanban - with Minions.

Explanation of Kanban with the help of minions. An argument for moving from Scrum to Kanban from the testers point of view.

Susan van de Ven

March 24, 2015
Tweet

More Decks by Susan van de Ven

Other Decks in Technology

Transcript

  1. Kanban Principles ! The basic principles of Kanban for software

    engineering ! Limit Work in Process (WIP) Pull value through (with WIP limit) Make it visible (Visual Control) ! The team continuously monitor the above to improve
  2. Why Pull? ! Don’t build features that nobody needs right

    now Don’t write more specs than you can code Don’t write more code than you can test Don’t test more code than you can deploy
  3. But..... ! • What if I am blocked? make it

    visible, try to help, discuss if story should be moved off the board • What if there is nothing to pick up? help others get stories ready • What if I’m done and there is a blockage upstream? help unblock
  4. Proposal for board LTS Accepted In Test (2*) In Dev(2*)

    Ready(2*) * Number depends on team size but should match what your smallest group can handle ie QA
  5. Kanban Standups ! Start from left (LTS) to right (Ready

    for Dev) ! Why is this not live yet? Can we help you get this story Accepted? Do we have a bottleneck? Do we have a blocker not dealt with? Are we keeping to our work in process limits? Should they change? Are priorities clear?
  6. “A Happy QA” When we were doing traditional Scrum our

    board was often overloaded in the QA lane, cards would stack up as developers were churning out work at a high rate and our tester was seriously overworked. ! After setting limits on our Kanban board the team soon began to realise that they could no longer stack work up, once a limit had been reached there was no where to go and the line would become blocked, so they started assisting the QA and testing work that they hadn’t written. Several months in we now have more manageable board, the QA isn’t overworked and the team pull together like never before.
  7. Decisions to make • Agree on WIP limits • What

    to do with high priority last minute request • Do you still need to split stories? • When does the story get discussed before development starts • what to do when story is blocked • what/how to measure • getting non-stories (tech debt) on the board • When to have retros ! !