Skip to main content

Kanban - An Introduction By:Namrata Parik

Scrum addresses the software development where the requirements are frozen before the sprint starts, but what about the teams which work on dynamic requirements which can come at any time?
For example in a team which works on technical tickets, these tickets may come at anytime and hence the sprint cannot be decided, estimation cannot be done and the velocity cannot be calculated.
Kanban is the solution to all this. Started in Toyota, Japan this was introduced to increase the productivity of the factory.
‘KANBAN’ in Japenese, means a visual signal.
Kanban was later used as an effective method in agile software development and it can be implemented in teams where requirements are not certain. The work items in this approach, are put on a board where each team members can access and update their work.
The team can have a physical or virtual Kanban board. Colocated teams prefer to have a physical board. The basic function of the Kanban board is that the team can visualize their task and discuss and solve any impediments they see immediately. A basic Kanban board has a three-step workflow: To Do, In Progress, and Done. However this might be changed depending upon the business needs and team requirements.

Image courtesy:brodzinski.com
This approach requires transparency of work and communication of capacity, therefore it gives the accurate picture of team’s performance.
All the information about that particular work item of the team is written on the Kanban card, which gives the entire team a clear picture about who is responsible for a particular work item, what work has to be done and how much time is that work item going to take. A kanban team is only focused on the work that's actively in progress. The Product owner has the task of updating the backlog actively and the team members after completing their task can take the next task from the backlog.
Hence, here it becomes very important that the backlog is actively groomed so that the task with the highest priority are on the top. Since the tasks with highest priority are always delivered the development team can be assured that they are delivering maximum value to the business.
Therefore the need for fixed length sprint is eliminated, task prioritization is done on the go and task estimation has to be done immediately after as task comes in.
A few other features of Kanban approach,
  1. The team is cross functional which means that the task of testing a work item is not blocked due to the non availability of testing team, the developers are also equipped to do the testing if the need arises.
  2. Multitasking is eliminated, this is not to be confused with cross functional team. Multitasking leads to reduced performance if a developer has lot of tasks ‘in progress’ then while trying to complete all of them, none of them will be fixed completed leading to no business value. This can be addressed by limiting the number of tasks in ‘in Progress’ category to a macimum of two tasks, for example.
  3. Charts – Various charts are available to measure the team metrics.

    Image courtesy: kanbantool.com
There are control charts to see the cycle average for each issue
There are also charts to indicate what task is in what state – to do, in progress or completed.

Comments

Popular posts from this blog

User Story In Agile Scrum - By Ankur Mistry

In this article, we will learn what User Story is and how to write one. User Story plays a major role here. It is the part of the Agile process where instead of writing comprehensive requirements, we write a short description of a feature. As the  Agile Manifesto  says 'Working Software' Over 'Comprehensive Documents'. What is User Story? User Story is a short and simple description of the feature or requirements of the project. Generally, user stories are written on sticky notes or index cards as a user or role-based perspective. User Story Template As a < type of user or role >, I want < some goal > so that < some reason >. The template identifies 3 questions - "Who", "What", and "Why". If the team doesn't know these three answers, it means they don't understand the story, and if they don't understand the story, then it's difficult to split it well.   Reference:https://mazoea.wordpres

Visual Studio Team Services - Agile - Scrum Project Management Tools

Before starting this article let's understand what is Agile and Scrum.  What is Agile Agile is a  Method  of project management that is characterized by dividing module in to tasks and t asks into short phases of work and frequent reassessment and adaptation of plans. In other words, Agile is a Time Boxed incremental software development method.  What is Scrum Scrum is an incremental agile software development framework  (Agile Framework).   Agile Scrum Process in Short. Product Backlog:  A product owner creates a customer’s wish list and prioritized it and create backlog, called Product Backlog. Sprint Planning:  In this meeting team select small part or module from the Top Priority Wish List of Product Backlog and prepare a small task list. Setting Capacity and Sprint:  Team has to deliver the tasks in 2 weeks or 4 weeks sprint, here Scrum Master bind tasks with Time and User. Scrum Master’s role:  Is to make sure team focused on its goal. End of the sprint:  

The Burn Up Charts In Scrum By: Namrata Parik

I would like to propose a less-taken path in my maiden article to track the progress in scrum. We usually do it using the burn down chart which is relatively easier to understand as compared to the burn up chart. These charts help the team and stakeholders to see and track the progress at any point in the release process or sprint. Burn-down chart provides us the information showing the progress based on the remaining hours or story points from top to bottom. (The burn-down chart can be plotted using story points, task count or the remaining effort) This chart is a plot of expected remaining and actual remaining, this is the most used chart in scrum and since it has only two lines it is considered to be a simple chart. It does not cover the scope creep. So sometimes what might look like ‘no work ‘ done by the team may actually be a result of scope creep. The chart below reflects that the team has not done any progress in Sprint 5 and 6 as the story points remain the same. Image