Saturday, September 3, 2011

Scrum VS Kanban

Once a project team has decided that they want to execute project on Agile principles, next big question is which methodology to follow.
Ideally a project team should pick up one base methodology and customize or fine tune the processes to the project requirements.

Two very popular flavors of Agile are SCRUM and KANBAN.

What is SCRUM
SCRUM is basically a way of organizing projects using two important principles:
  • Product backlog: This is a list of all the work (Enhancements, New Development, and Bugs) which is required to be done for a product.
  •  Time Boxing: Product is delivered in iterations and duration for iterations is always fixed. It could be any duration generally from 1 -4 week(s). But once this is decided, it should not be changed.
How Scrum Works:
  • Sprint: At the beginning of Project a fixed duration for deliverable is decided. This is called a SPRINT
  • Product backlog items are prioritized and placed in a sprint. This gives product development road map
  • During each Sprint, backlog items are reviewed and re prioritization is done. This is done on regular interval to make sure that all the changes and new requirements which have come up since last Sprint are placed in product development plan.
Practical Problems with SCRUM
Scrum focuses on time boxing of development cycle. This could be a challenge for maintenance teams where fast turnaround time is required.  They may want to have releases based on priorities instead of waiting for a fixed time period.

For example in first iteration there might be 3 important issues which are required to be released and which will take 2 weeks to deliver. In next iteration this could be 1 week or 3 weeks. So holding on to the release to fulfill fixed duration requirement of SCRUM becomes challenging in environment where there is high pressure from clients for fast turnaround time.
·        
     Sometimes it’s difficult to freeze the priorities even for a small sprint. What if an urgent issue comes up? Should the team keep on waiting for the current SPRINT to be completed to pick up the urgent issue, or should this be picked up immediately?

KANBAN
Kanban eliminates the need for time boxing while maintaining most of the other principles of AGILE intact.

Kanban focuses on continues delivery approach by focusing on limited items at a time

How Kanban works:
Step 1: Define stages of development: 
Each work item, needs to go through different phases from initialization till completion. These are called stages of development. For example the stages could be
  • Requirement gathering
  • Design
  • Develop
  • Test
  • Release
This is the sequence which is required to be followed for completion of an work item. This sequence could be different for each team and needs to be defined based on project requirement.

When one work item goes through all the stages of development that is called a completion of one Cycle

Step 2: Fix Work in Progress (WIP) for each stage:

After the stages of development are defined next step is to fix the max work in progress items for each stage
For example if it is decided that requirement gathering team can pick only 3 items at a time to define requirements. Unless any of these current item is completed, any new item is not picked up and is kept in a queue. Till the time team is working on current item in hand, priority of queue can be changed any time. Only when one of the items is completed next item from the queue is picked up.

Step 3: Manage Work Queue for Each Stage:
Work Queue for each stage is managed to ensure WIP limit in maintained for each cycle. One work item passes through work queue for each stage in life cycle. It is completed when it passes the last stage of the life cycle.  

This gives flexibility to re prioritize at any stage of life cycle.     

Scrum Vs Kanban Diffrences
Scrum
Kanban
Time boxed delivery
Continuous Delivery
Predefined roles for team , scrum master and product owner
No Prescribed Roles
Work is managed in sprint backlog and cannot be reprioritized once sprint started
Work is managed in Queues for each stage and can be reprioritized as long as it’s still in the queue
Batch work is picked up to create product backlog
One item is picked up at a time
Team productivity is assessed using team Velocity which is the average number of story points completed in each cycle
Team productivity is assessed using Item Cycle Time. This is the average time required by an item to complete one full cycle from first stage till the last stage

Scrum Vs Kanban Similarities


  • Both are lean and Agile
  • Both focus on cross functional teams
  • Both are focused on end delivery 
  • Both promote small incremental releases
  • Both promote transparency in the team and flat team structure


Which one is Better SCRUM or KANBAN
Both SCRUM and KANBAN are designed to deal with specific problems.  While SCRUM should be a good practice for a product development, KANBAN can be adopted by Product maintenance teams where turnaround time is of extreme importance. 


Scrum Simplified

SCRUM is an agile methodolgy for software projects.

There are 2 ideas which form the core of SCRUM : :
  • Maintain Product Feature List  ( called Product Backlog )
  •  Time Boxed Development (called Sprint)
The Product Backlog is the master list of all functionality desired in the product.
It is not necessary to start a project with a lengthy, upfront effort to document all requirements.

Typically, it starts with a small list and it grows and changes as product evolves.

It helps in following ways:
  • It helps maintain one single list for all product Requirements.
  • Tracking: A status is maintained for all backlog items which give visibility of what is complete, what is current work in progress and what the future plans are.
  • Prioritization: List of features can be prioritized based on business scenario to align development with the business need.
  • Estimation: Each Backlog Item has a rough size and complexity estimate. This helps in
  • Planning the work for future iterations/Sprints.
  • Understanding team productivity based on work completed in previous iterations/Sprints
Development is divided in small iterations called SPRINT:
  • A Sprint has a fixed period (generally 1 – 4 weeks).
  • Once decided Sprint period is not changed. This helps in setting a rhythm in the team.
  • Every Sprint has a defined Start and End Date.
  • A Sub set of backlog Items from Product Backlog are taken and assigned to the Sprint. This is called Sprint Backlog.  This defines the target or the output for the sprint.
  • End Date for sprint is fixed; if all the items from sprint backlog could not be completed they are moved on to future sprints.
  • The Sprint Backlog Items are prioritized as
    •    Must Have
    •    Good to have
    •   Nice to have
  • All the “Must have” items should be completed by the end of sprint. “Good to Have” and “Nice to have “could be picked based on time available.

  • All work should be present in Product backlog and there is no requirement outside it.
  • The End date of Sprint is fixed.
  • Once a sprint has started, Sprint backlog items in that Sprint should not be changed. If there are changes coming up in the work under progress, they should be captured separately and assigned for future sprints.

  • Daily Standup Scrum Meeting by Development team ( less than 15 minutes each day ) where each team member  tells about :
    •  What was done yesterday
    •  What is planned for today
    •  Any Blocker in doing the work
  •  Lessons Learnt or retrospective Meeting at the end of each sprint to evaluate what worked and what not and find out ways of improvement.
  • Sprint Pre Planning Meeting: here the work for the sprint is planned before start of the sprint.
  • Sprint Demo Meeting: This usually is used to give a demo to stakeholders from dev team as to what work was completed in the sprint.
  • Sprint Burn down Chart: The estimated work remaining in the sprint is calculated daily and graphed, resulting in a Sprint Burn down Chart. The vertical axis displays the hours of effort remaining for the Sprint.  The horizontal axis displays the days of the Sprint.  The burn down is supposed to be shown by the line of descent from the start of the Sprint with the starting hours, down to the end of the Sprint with no hours remaining. 
  • Product Burn Down Chart: No of features completed in each sprint.
  • Sprint Velocity: No of Backlog Items completed by team in a sprint. This helps in planning work for future sprints.
Following lists are required to be maintained:
      1.  Sprint List: List of planned sprints.

      Required Fields:
  • Sprint Name
  • Start Date
  • End Date
  • Description

      2.  Product backlog List: List of all the product features

       Required Fields:
  • Backlog Id : an auto generated field
  • Dependency : multi select list where backlog ids of other features can be filled
  • Sprint: Combo Field coming from Sprint list. This helps in defining sprint backlog
  • Release ( e.g. 1.0 , 1.5 etc ) : release in which this feature is planned
  • Week (  within sprint  which week this feature will be developed )
  • Module: a logical division of features ( e.g. User, Account etc)
  • Sub Module : a logical sub division of features
  • Category ( e.g. :New Screen, Workflow, enhancement,Bug  etc)
  • Backlog Item Title
  • Backlog Item Description
  • Complexity ( Complex, Medium, Simple)
  •  Priority ( must have, good to have , nice to have)
  • Status ( not Started, In Progress, Completed, On hold, Released)
  • Assigned to
  • Time Estimated
  •  Time Spent
  • Time Remaining
  • Remarks
  • Source :  This item was requested by whome or was promised to whome ?
  • URL of  document location ( These are detailed requirement document or link to a wiki page for this backlog item)
      3. Task List: list of all the task required to be done for development of a feature. Should be a child of a feature/ Backlog item

      Required Fields
  • Task Title
  • Sprint
  • Backlog Id
  • Task Description
  • Time Spent
  • Start Date
  • End Date
  • Assigned To
     4.  Optional - Release Plan : expected release plan for the product : required only if multiple sprints are to be clubbed for a release

      Required Fields
  • Release : ( e.g. 1.0, 1.1. 2.0)
  • Dev Complete Date
  • QA Complete Date
  • Move to staging Date
  • User Acceptance testing  date
  • Release Date