The Product Backlog in Agile


By now most you may have heard the term “Product Backlog” in Agile terminology. You can consider this term to be referring to our erstwhile vocabulary of requirements documents with a slight twist.

Requirements Management

The point about managing requirements in Agile is that you can use any tool available to manage what is needed to build the product. It could be a wiki, it could be jIRA, it could be Rally or even an excel sheet. The means to detail requirements do not matter. What matters is how the requirements are listed, when they are ready for design and execution, when and where they are discussed with teams and how they are made more and more clearer as time progresses. We need to maintain this essence while handling the requirements.

So coming back to product backlog – think of it as a list of requirements to build a product with two important considerations: the priority to develop a listed item, and the clarity available to implement a listed item. Priority obviously means what is more important to do (even in normal life). Clarity available means what is actually Ready.


Continue reading “The Product Backlog in Agile”

Capacity & Velocity — is there a connection?



Being a new methodology, Agile obviously comes with its own terminologies and nomeclatures. But these are not necessarily something that we already do not understand.

What is needed is for our minds to understand the mapping of what terms mean in the new methodology to what it meant in the older ones we used. We will discuss Capacity & Velocity today, which are two important but not difficult to understand terms we need to know when it comes to implementing Agile within our teams.

Continue reading “Capacity & Velocity — is there a connection?”

The formality called ‘Agile Ceremony’



For people coming in from different methodologies, the word ceremony may sound very formal while entering Agile. However what it really means is that Agile as a process, recommends certain checkpoints where the work progress can be measured, and course corrections can be taken in order to enable the team to still chase the sprint goal.

The Agile methodology recommends the following ceremonies.

Continue reading “The formality called ‘Agile Ceremony’”

The key expectation for Agile based project deliveries


I always like to attribute many things we do at work to a real life example elsewhere, say at home.

Let’s consider that you order a pizza for your family at home. You give your requirement, your contact information and pay for the delivery either upfront or when the delivery takes place.

From the moment you order the pizza, your patience has a limit of waiting for the delivery boy. Perhaps half an hour, or an hour after which you will begin to consider what to do next. So finally the pizza boy comes in and hands over a pizza. You are smiling, your family is happy and you are feeling great that you got what you ordered.

But just then you notice that you have got a 9 inch pizza instead of a 12 inch one. You ordered a panneer pizza (veg), but you got a pepperoni pizza (non-veg). And the boy arrived an hour and a half late so your pizza is cold and not edible anymore. You are seething with anger and decide to cancel your order. For good reasons. The delivery did not meet your requirements.

This example is somewhat a simple one, but brings about the fundamental things that one would like to expect while committing to a job for delivery.

Continue reading “The key expectation for Agile based project deliveries”

Kicking old habits to unlearn



When you hear someone tell you their team is ‘moving to agile’ the first thing one tends to ask them is — ‘oh really? so from now you are all going to be agile isn’t it ? Cool !’

This question stems from a bit of surprise that the person asking the question either does not seem to understand what Agile is going to significantly change for the team in question, or it could be just plain sarcasm of otherwise putting it as ‘Ok, so you are agile — how’s that gonna alter anything in what you do? It’s just another jargon in the industry’.

Continue reading “Kicking old habits to unlearn”

Buy in from senior management


Following one of the known Agile frameworks such as Scrum, or Kanban within a team is an easy decision to make compared to doing the same thing at a division or organization level.

The moment the notion of the whole division going Agile is envisaged, there are lots of complications that immediately present themselves in front of us. Basic questions may stump organizations towards this kind of move.


Continue reading “Buy in from senior management”

Welcome to real agile

real agile” is a blog that I started today to begin to write about implementation of agile methodologies in projects which are serious about their outcomes each for each iteration of work. Through this blog, I will try to put in my experiences of transforming teams from traditional methodologies to the Agile way of working. This blog will also cover mainly the Scrum framework of Agile, roles of team members in Agile, and more advanced topics such as scaling Agile within an organization. The blog intends not to be a rule book by which Agile must be implemented or followed but rather, a set of guidelines derived from real experiences.

As you would know, while the Agile manifesto specifies ground rules of how projects should implement Agile, in reality organizations worldwide, and specifically in India (since I live and work here) are yet to derive the maximum benefit out of implementing Agile in a result oriented manner. There are a good set of companies in India that are executing Agile with self organized teams, but there are many more who need to know how to use the nuances that Agile specifies and inspect and adapt along the way.

I hope the articles in this blog are used for teams to adopt Agile and execute the projects towards outcome driven iterations.