Scrum framework : Scrum Board, Agile Board, Kanban Board, Sprint Board, Tasks Board, Team Board, Refinement Board and others ?

Original post

• See the original post on https://scrumschool.org/academy/blog/Effective-Collaboration-on-Sprint-Board

What is a Team Board ?

• Almost all Scrum Teams use a type of board to visualize their work giving them a better understanding of where they are currently and helping them make upcoming decisions.
  • In addition, it is a place where the whole team can get aligned continuously and create a gentle flow of value delivery.
  • However, there are a bunch of techniques helping Scrum Teams experience effective collaboration.
  • Although we cannot prescribe them for all teams, they proved that they work and are fundamentally good practices worth using.
• So, let’s get started by investigating the techniques of collaboration on Sprint Board one by one:

Collaboration and Tasks Board

• 1-Limiting the WIP
  • In short, it says if you decrease the concurrent number of open PBIs (Product Backlog Items), the team’s productivity increases.
  • Based on this rule, we have the concept of WIP (Work in Progress) on Sprint Boards by which you can set your WIP number on every single column.
  • When you exit the WIP limit, the column informs you in a way like highlighting the column or the actual number of PBIs in that column.
  • WIP Limit
    • A very simple way of defining your WIP limit number is dividing your Developers’ number by 2, rounding it up, and putting this limit on your Active column.
    • Then you can adjust the WIP limit number by inspection and adaptation over time to find your team’s optimum WIP number.
• 2-Pull system
  • To create a smooth stream of value delivery, you should work like a pull system.
    • It says, every time you check your board, you should focus on the PBIs that are currently at the end states on your board and try to move them first and then check other PBIs from the right to the left side of the board.
    • This way of working ensures that you first focus on the PBIs that are more probable to be done.
    • Moreover, it optimizes your investment as it doesn’t allow you to keep an open PBI for a long time on a specific state on the board.
    • In addition, it brings constant energy to the team as they continuously see PBIs getting done one by one.
• 3-Having a Blocked state
  • Transparency
    • When you add a Blocked or “On Hold” state or whatever you call on your Sprint Board, it increases the transparency.
  • Rule
    • The rule here is that you should be ruthless about the issues or impediments that put a PBI in the Blocked state.
      • By putting the collective energy of the team on the blocked items, you change the PBI status as soon as possible.
      • Again, by this way of dealing with blocked PBIs, you guarantee that you still have a gentle flow of value delivery.
• 4-Last holy step of your board
  • DoD, Done and Done-Done
    • Be cautious of your board’s last state which is usually the state of Done or Closed.
      • It is the state that you make sure the PBI complies with the Definition of Done (DoD).
      • Here you may need to check again your DoD and update it as you are about to use it actively.
      • Then whenever you want to drag a PBI to the last step, check it completely with your DoD and just close it when it fully complies with the current DoD.
      • Caveat
        • Done can be seen as a holy concept in Scrum.
          • Indeed, if we wanted to squeeze Scrum into one sentence, it would be creating Done increment.
          • So, maintain the Done concept holy as it literally is and teach the whole team to do so.
        • By such behavior, you are always sure that you create completely releasable PBIs without any remained tiny work which supports your Product Owner to be nimble about making the release decisions.
• 5-Don’t assign a single PBI to a single Developer
  • Prerequisite in Scrum
    • Software development is a Team sport.
      • A team can win when all team members work together with a high level of collaboration.
      • Indeed, we want to have collective PBI ownership by which every Developer on the team feels responsible for that PBI.
      • If you assign a PBI to a single Developer, when the team is inspecting the board and that Developer is absent, the likely behavior is that they skip that PBI as they think it has an owner and they don’t know what the latest status of that item is.
      • On the other hand, by limiting the WIP, Developers have to work together on shared PBIs which naturally prevents assigning a PBI to a single Developer.
      • There are three ways for Developers to work together : swarming, pairing and mobbing.
• Swarming :
  • All Developers (alone or pairs) work on a single PBI, working on multiple tasks in parallel until the PBI is Done.
• Pairing :
  • Two Developers collaborate closely on a single task, one is the driver who has the keyboard and the other one is the navigator who reviews the work at the same time. Pairs may be part of a larger swarm on a single PBI.
• Mobbing :
  • All Developers work on a single task, of a single PBI, then the next task of that PBI until the PBI is Done.
• Ideal state :
  • The ideal state, which is a sign of a high-performing team, is using swarming practice regularly which gives the team a sense of flow, energy, and being alive.
  • So, challenge yourself to learn and use it in your team and experience the high-performing state of feeling.
• 6-Expedite Lane
  • Class of Service concept
    • Having unplanned and urgent work is part of reality.
      • The way we deal with such work determines our level of performance.
    • A good practice here is using the concept of “Class of Service”.
      • By this concept, you divide your board horizontally into two or more lanes.
      • All PBIs in a specific horizontal lane are served differently based on the lane definition.
  • Expedite Lane
    • So, here we can add a horizontal lane for managing urgent work called usually as “Expedite Lane”.
      • However, to use it effectively you need to follow two rules of this lane.
      • Rules
        • The first rule is that the lane should always be clear and the whole team is responsible for its clearance.
          • To do so, the first action is to determine if it is really important and urgent to interrupt the team’s focus or not.
          • If the answer is no, put the item in the Product Backlog then it can be selected in the upcoming Sprints like regular PBIs.
          • But if the answer is yes, then Developers put aside their current work and swarm to see what the urgent work is.
          • They collectively decide how they want to manage the urgent work.
          • It is suggested at least two Developers take responsibility for the work.
          • This policy makes sure they will work in pairs by which the work review is done simultaneously and increases the likelihood of closing the work in a short period of time. It helps the team keep their Expedite Lane always clear.
        • The second rule is that after closing the urgent work, we need another step of having a root cause analysis to see why such urgent work happened.
          • It may lead you to improve your processes preventing occurring the same thing in the future.
          • Consequently, it helps the Scrum Team decrease the amount of urgent work over time.
• 7-Burndown chart
  • You know that the purpose of having Daily Scrum is inspecting the progress toward Sprint Goal and adapt the upcoming work based on the latest lessons learned.
    • One of the proved practices to inspect the progress toward the Sprint Goal is visualizing the progress usually by a Burndown chart. So, use it actively to have a meaningful Daily Scrum.
    • But before that, the prerequisite is having a strong and concrete Sprint Goal something that all team members believe in and is aligned with the Product Goal and of course, the Product Vision.
    • Burndown Chart
      • So, think of it deeply and try to create motivating Sprint Goals, then use the Burndown chart purposefully and enjoy progressing every day in Daily Scrums.
• 8-Refinement Board
  • As I already mentioned we want to create a gentle flow of value delivery pipeline.
    • So, we need a mechanism to make sure that we always have enough refined PBIs ready to be picked up for the upcoming Sprints.
    • On the other hand, refinement work is context-based and each domain has its own definition of refinement.
    • I do not want to talk about it but I recommend you have a separate refinement board giving you a visual information radiator to be sure that you are always ready to start a new Sprint by having enough number of ready and refined PBIs.
  • With such a policy, you keep your eyes on it, and like a pull system, you can decide to have refinement sessions every now and then when the number of refined PBIs decreases.
• 9-Flow Metrics
  • Metrics and definitions
    • Flow metrics
      • One of the greatest policies to improve the fluency of your value delivery pipeline is using flow metrics.
      • In “The Kanban Guide for Scrum Teams” document published by Scrum.org, you can see four flow metrics as follows:
    • WIP
      • WIP: I talked about it before.
    • Cycle Time
      • Cycle Time is the amount of elapsed time between when a PBI work starts and when its work finishes.
    • Work Item Age
      • Work Item Age is the amount of time between when a PBI work started and the current time.
      • This applies only to PBIs that are still in progress.
    • Throughput
      • Throughput is the number of PBIs finished per unit of time like a Sprint.
    • Lessons Learned
      • I recommend you use these metrics and see how wonderfully they affect your Way of Working (WoW).
      • Hope these techniques help you improve your productivity as a Team and enjoy working together.

References :

• Professional Scrum Development with Azure DevOps book by Richard Hundhausen.
• “The Kanban Guide for Scrum Teams” document published by Scrum.org

Versioning

• Created on 01/04, 2023.
• Updated : 01/16, 2023.