Scrum-Ban / Kanban with TeamForge Project


TeamForge Project (TFP) is a flexible tool where it can support multiple software development methodologies.  In this article, we will specifically focus on how you can use a scrum-ban methodology with TFP.

Scrum-Ban Explained

Scrum-Ban is a variation of Kanban methodology.  Therefore, let us first define Kanban.  Kanban is literally the Japanese word for sign, or visual card.  The Kanban methodology has its roots from lean manufacturing.  For example, Toyota used Kanban cards (physical card) in manufacturing to support non-centralized "pull" production control.

Kanban methodology in Software has few rules:

  • Visualize your workflow
  • Limit your work in progress
  • Manage flow
  • Make process policies explicit
  • Continuous Improvement

Scrum-Ban is a variation of Kanban where we take some elements of SCRUM and incorporate it into Kanban, in CloudForge, we add the following:

  • Product Backlog, stacked ranking, and grooming
  • Daily Scrum Meetings
  • Monthly Retrospective Meetings

Agile Scrum vs. Kanban

Here at CloudForge, we use both Agile SCRUM and Scrum-Ban.  The reason is that each methodology is suited for different needs.

  • Agile SCRUM - great for projects that require focus, where you can dedicate resources without interruption, and require explicit processes to manage stakeholders and product owner input via the product backlog
  • Scrum-Ban - great for reactive situations where developers are constantly interrupted, require greater flexibility of changing tasks that are worked on

One quick way to decide whether you should use Agile SCRUM or Scrum-Ban is: can you live with locking down your sprint backlog for 1 month or 2 weeks (depending on the length of your sprint) without interrupting your SCRUM team?  If the answer is no, then Scrum-Ban may be a better methodology for your situation.

CloudForge Scrum-Ban

Here is how CloudForge does Scrum-Ban.

  1. At CloudForge, we use Scrum-Ban for our sustaining engineering.  The reason is that at any moment in time, we may get a crucial bug that requires immediate attention.  Therefore, the Scrum-Ban methodology works well.  For new feature development, we use Agile SCRUM methodology.
  2. We use TFP to track our Product Backlog (PB).  See this article for more details: Agile SCRUM with TeamForge Project. . Specifically, refer to the section titles:  Product Backlog Planning Folders, Setting up Your Product Backlog Planning Folders
  3. Once you have your PB, you should stack rank your Product Backlog Items (PBIs) as much as you can
  4. Even though Scrum-Ban does not require sprints; it is continuously PBI in, PBI out, we find it helpful to have monthly breakdown of PBIs accomplished.  Therefore, we create sustaining sprint folders.
  5. kb2.png
  6. For example, 3/2011 is already over, therefore, we will simply move PBIs that are not completed to Sustaining Sprint 4/2011 and mark Sustaining Sprint 3/2011 as completed.  Again, this is simply for tracking PBIs on a monthly basis
  7. We will then add a few more PBIs into the 4/2011 planning folder.  For a team of 3-5 people, a stacked rank list of no more than 10 items in total is good.
  8. At CloudForge, we visualize our workflow of PBIs via stacked rank list of PBIs.  In the image below, artf1672 has the highest rank, followed by artf1670, then artf1671.  Click on the Rank button on the right to show stacked ranking.
  9. kb1.png
  10. Team members in the sustaining team know to take the PBI on the top, assign to themselves.  That way, other team member knows that PBI has been taken.  Sometimes, a team member may skip the highest ranked PBI even if it is unassigned; the reason is that he may not be the best person to work on the PBI.
  11. We use TFP to track remaining effort.  Team member enter this daily.  This will allow everyone to see when the PBI will be finished.
  12. task1.png
  13. If there are only 3 PBIs that are unassigned, and your team of 5 developers all have remaining effort of 8 hours, then it is time to add more PBI from the PB into the current sustaining sprint
  14. Remember, product owner can always add new PBI and give it highest rank at any time
  15. Near the end of the month, we will hold a retrospective meeting to see if we can improve our development processes

At CloudForge, we found that Scrum-Ban is a really easy process to adopt.  You can start with any set of PBIs that you currently have, get started right away, without any organization change.  In addition, Scrum-Ban is great for distributed agile teams.  For example, if a team member in the Indian time zone finished up his current PBI, he knows exactly what to do next.  He goes to the Scrum-Ban board, look at the stacked rank list, and pick the next PBI.  This type of decentralization, self-management, and self-organization is powerful in a distributed team.

There are tradeoffs with Scrum-Ban.  For example, you don't really do estimation up front.  Also, it is not possible to commit on getting a certain PBI done because the team member always face the risk of interruption from higher priority PBI.

Here is a summary of CloudForge Scrum-Ban:

  • Visualize your workflow - CloudForge's Kanban board is the TFP Ranked list view in the context of the planning folder
  • Limit your work in progress - the limit on work in progress is 1 PBI per team member, in other words, a team member can work on 1 PBI at a time
  • Manage flow - CloudForge manages work flow via PBI status (Open, In Progress, and Closed), assignment (to a specific team member), and adding additional PBIs from PB
  • Make process policies explicit - many of these processes are already discussed in the previous bullet points, another example would be team member entering their remaining effort on a daily basis so that other team members can see when other PBI will be finished
  • Continuous Improvement - the monthly retrospective meeting is our way to discuss ways to improve our processes


In Kanban, there are two metrics for tracking:

  • Lead Time - starts when a request is made and ends at delivery
  • Cycle Time - starts when work begins and ends at delivery


A big difference between lead time and cycle time means that there are not enough resources to handle all the items, therefore the lead time is much longer than cycle time.

At CloudForge, through TFP, we can find out lead time and cycle time for specific PBI because TFP tracks every status changes or planning folder changes.

  • Lead Time
    • Starts when you move a PBI into Sustaining 4/2011 planning folder
    • Ends when PBI status is closed
  • Cycle Time
    • Starts when status is In Progress
    • Ends when PBI status is closed



Article is closed for comments.