How agile is your project: Part 2: Scrum and Kanban

In the last post, we saw what Agile methodology is and its manifesto. We saw an example of how Agile can be used by a tailor Bharat to sew a shirt for a customer Aditya. While we talked about Agile through a story, there are formal ways of planning and keeping track of projects using Agile. Two of them are Scrum and Kanban.


Scrum is a way to work on a project in fixed chunks of time. While working on a project using Scrum, the project is broken into deadlines at fixed intervals of time. The time available between two successive deadlines is called a sprint. A typical project has a sprint of 2 weeks. Tasks are set for each sprint and a sprint is called successful when all the goals are achieved.


The tasks set during a sprint are fixed and changes can be made only during the next sprint. This is designed so that a project can be worked on without interruptions in between deadlines and no confusion is created by changing tasks on the fly.

At the end of every sprint, a sprint review is done to see if the sprint’s tasks were achieved. If so, then the sprint is considered a success and used as a model for further sprints. If some tasks were not achieved, then problems are discussed and recorded in the backlog. These tasks are considered for successive sprints. The roadblocks that made the tasks unachievable are discussed and the ways to solve them are sought.

Scrum participants


Scrum needs persons playing three roles: the owner, the scrum master and team members.

The owner is the person who specifies the requirements of the client. The owner takes the call on what should be done during the next sprint. All the tasks for the spring are recorded in a document called the backlog. The term backlog seems negative, but is just a misnomer for a to-do list. The owner continues recording tasks in the document even after the tasks for the current sprint are decided, so that those newly recorded tasks can be considered for the next sprint. In that sense, the new tasks are in a ‘backlog’, since they are not considered right away.

The scrum master is the facilitator whose responsibility is making sure that the tasks set during the sprint are achieved. During the sprint discussion, the scrum master’s job is to assure that the team members have everything they need to work on the tasks. Questions are asked to ensure that the team members understand the requirements and if there are lingering doubts. It is made sure that the team members have all the resources necessary to work on and complete the tasks.

The team members are the people working on the tasks set in a sprint. They must be fully aware of every requirement during the sprint. It is desired that they bring up concerns during the sprint meeting itself. Along with the scrum master, they should negotiate with the owner to fit in only as many tasks that can be possibly done during the sprint.

An example

Let’s take the shirt sewing example again. We introduce Chandrika, the owner and Daisy, the scrum master. Chandrika continuously talks to Aditya and stays on top of the requirements. She records feedback and puts them in the backlog. Whenever Aditya mentions anything that he needs done on the shirt, Chandrika’s backlog gets the entry. Bharat, Chandrika and Daisy have decided that they will show the progress to Aditya once every two days. So a sprint lasts two days.

At the start of every sprint, the trio spend not more than half an hour in a stand-up meeting to discuss what should be done during the next sprint. While Chandrika discusses the next set of tasks, Bharat keeps the trio informed about how much time each task would take. Chandrika and Daisy listen to everything Bharat has to say. Then Chandrika finalises on the tasks she decides are of priority during the next two days to take the shirt to the next level. For instance, let’s say that the shirt’s torso and sleeves have been sewn already. During this sprint, it is decided that the collar needs to be attached and that the buttons on the front and the cuffs need to come on. The stitching of a pocket on the left breast of the shirt can wait till the next sprint.

Daisy makes sure that Bharat has no problems with the sewing machine and that he has the coloured buttons and threads available for the next set of tasks. Bharat can approach Daisy anytime he thinks that there is a problem. Daisy either solves the problem for Bharat if it is in her capacity or takes it down as a point to be discussed during the sprint review.


Kanban has trickled into software engineering from the manufacturing field. Software practitioners studied Kanban and its success at Toyota and brought it on a test basis into software. It worked and since then, Kanban is used by some companies to roll out software. Kanban is especially good when there are multiple teams working on a software as if it were an assembly line.

Kanban uses a principle that is central to manufacturing. Different teams have different capacities. A certain team has less capacity than the rest, typically because their process is more computationally expensive or because it needs more manual work than can be fully automated, e.g. graphic design which needs manual creativity and a type of thinking which matures the design the more time it is given. This less-capacity team is always to be kept fully utilised during its working hours. This team is called the bottleneck.

By working back from the delivery deadline and based on dependency between tasks, a sequence in the form of scheduled dates and deadlines is created and assigned to each team, making sure that no team works above its capacity at any time. The bottleneck team also never works under its capacity.


For each team, there are three sheets of tasks at different levels of completion: To do, Doing, Done. The sheets for each team are seen publicly, so that teams can collaborate. The ‘To do’ sheet tells a team what work is coming up. The ‘Doing’ sheet contains all the tasks that are currently being worked on. This list should never have more items than the team’s capacity. The ‘Done’ list contains the list of tasks that are complete. Tasks flow from ‘To Do’ to ‘Doing’ to ‘Done’. When every team has moved every task from ‘To Do’ to ‘Done’, the project is complete. As the project progresses, more items can be added to a team’s ‘To do’ list.

Here is how each team works. It checks the ‘Doing’ list to see if the team is running under capacity. If every team member has tasks assigned and none can take up any more tasks, then the team continues to work. Otherwise, it reviews its ‘To do’ sheet. They check if the tasks in ‘To do’ are dependent on the completion of tasks by another team. If there are no dependencies, the team picks up the task immediately. If a task depends on tasks by other teams, then they check those teams’ ‘Done’ list to see if those tasks are done. If so, then the task from ‘To do’ is picked immediately. On picking a task, it is moved to the ‘Doing’ list and when done, to the ‘Done’ list.


As Agile gets more adoption, project management methods like Scrum and Kanban will become popular and ultimately mainstream as waterfall model will be completely phased out from technology. In addition, there will be other methods as technology changes and different types of problems are solved with computer automation. For now, a mastery over Scrum and Kanban will make your project more responsive to changes and help timely delivery.



3 thoughts on “How agile is your project: Part 2: Scrum and Kanban”

Leave a Reply

Your email address will not be published.