How Does Agile and Scrum Relate To Each Other


It goes without saying that basically we are big fans of agile software or product development and we more often than not use scrum methodology to drive projects through to completion

One can always anticipate agile as a project management philosophy and scrum as a guided framework to back with which you can use to implement it. Scrum always comes with a particular set of rules and path to choose which needs to be implemented day to day.  Primarily agile methodology came to life in response to an issue, software projects were overshooting deadline and also the budget allocated to it. Windows 2000 came in late, so did Vista which was in fact very late and quite unstable when it was launched at the very first time. If you recollect well all of these releases were developed using the traditional project management methodology popularly known as the waterfall model which comprises of…

Planning, Design, Development, Testing, and finally Delivery

The waterfall model as everyone knows has a very long and distinguished past and history, eventually it was found having limitations for software development kind of projects in the age of the internet and rapid networking. It’s the age which is considered where products become out dated very quickly and are most often considered in a lifelong or permanent state of either evolution or extinction. Current scenario is Microsoft has embraced agile completely, its simply because agile has proved all other previous approaches look like a failed exercise. The power of agile is it backs releasing software in iteration or in other words incrementally instead of attempting to deliver all at once in a single build. It is basically this incremental style of software release which has led agile completely taking over the software development landscape. To an extent that it’s been believed that almost less than 10% of projects currently apply and use the traditional waterfall model for project management approach.


Ideally scrum works by cutting down each project deliverable into a bite size chunks, setting up a priority and then delivering them in short releases called sprints. Yes and to give an analogy it was indeed based on the concept taken from the game of rugby. The worldwide reach of scrum framework is more likely coming from the way it handles the complexity and frequent changes. It actually does this in a much similar way to how I or you would when facing with quite an amount of work in hand and not much time given to complete it.

The Product Backlog

In this particular part we generally write or list down all of the tasks or features you would intend to finish. In the scrum terminology it’s often called as user stories and we need to describe the user of the software that the feature is basically for and what they want to do and why.


Each and every user story is given a score based on the anticipated complexity of the feature to develop, some of the most common ways to estimate include similar to t-shirt sizes like S, M, L, XL etc. with the powers of 2 like 1,2,4,8, or even applying the Fibonacci series 1, 2,3,5,8 etc. generally the Fibonacci series is favored at a scalable path.

Grooming Your Backlog

The user stories are then given priority of development sequence by the client, stakeholder or product owner based on the criticality and importance to its business and revenue generation. The user stories at the top of the product backlog need to be defined in very much detail so as to start working on them. It is not very important to define stories in detail which are of low priority and not like to be developed anytime soon, because time is very much critical factor in this sprints and feature development.


Once the user stories are sufficiently detailed in the product backlog, the scrum team or the scrum master decide together on a particular subset of the user story they think can be completed shortly. Now these user stories are put into a sprint and the development team concentrates on its development for the duration of that sprint.

Most experts recommend the sprint cycle to be of one or max two weeks long. Generally it depends on how much work needs to be completed mostly because of the overload which comes with each and every release. Normally a 2 week schedule reduces 50% of time we spend doing the deployment and releasing, if the project is well equipped with mature stable automated testing and deployment, releases can be done more frequently without taking in any overhead. The period of sprint you decide to go for will be unique and mostly decided by the scrum master, customer requirement and most importantly whether team is able to complete the work in this given time practically. There are some thoughts which generally assist you to make informed decision, it’s always important to remember that scrum is all about faster feedback and improvement, and shorter sprints which speed up the feedback.

It’s a known and a proven fact that a high performance scrum team often works much better under high pressure. Shorter sprints provide this pressure which the team thrives upon and makes sure the work is completed in the given time. It should always be kept in mind that each sprint is an independent shippable product, and if your team is relatively new or inexperienced and still you are being asked to work on larger tasks then bear in mind that you are going to need more than 2 weeks to achieve this deliverable. At the end of each sprint ideally you should have a new version of your software product, then this process keeps on repeating and the next set of most important features to be developed come in the pipeline, which are taken care of in the next sprint.


Iterative Development – Piece By Piece

The most stand out and important factor of scrum is its iterative development process. Scrum comes with set of guidelines

Scrum basically intimates the agile MVP approach which was pioneered by Eric Ries – it has a simple principle of starting with something simple and go on adding to it over a period of time. Scrum principles always come in pre-defined guidelines that have a most obvious assumption that requirements will keep on evolving this gives scrum more flexibility when it is actually implemented. This is just the reverse of traditional project management or waterfall approach that avoids changes because of non reversal process and the high cost involved into it.


Scrum always has been known for backing multi-disciplinary way of working in an organization where roles tend to overlap (that is the sole reason its been very popular in the startup companies). This particular approach is very result oriented at lowering human ego within the team members and giving team members a clear and concise understanding of the worth of other roles within the team

Scope Change

The basics of Agile and Scrum are based on changing requirements and scope and its even defined in the agile manifesto. The customer giving feedback which follows after every sprint is vital for them to ensure the product is being built as per their expectation and business requirement and still fits into the given budget allocated to this project.

Effective and Better Communication

When you develop a product in a iterative manner you have the flexibility to take on precious feedback on board throughout the process. Disconnected or less client communication in a waterfall model approach might not become relevant unless and until the product is in the final QA phase. Unlikely with agile scrum any issues are most probably to surface as early as possible in the cycle as features are tested in a particular sprint and not as a whole product. This seamless frequent collaboration between all the concerned is one of the prime reasons experts recommend using even for decentralized or remote teams where communication becomes very critical part of the whole product development process.

Glass Transparency and Ownership

As everyone is aware that agile scrum is basically built on complete transparency and scrum backs this by keeping all to do things and tasks with communication visible to all. It has been said that while being transparent is key to appropriate functioning of a sprint it has also leveraged benefit of increasing the team’s performance.


Ajay Girme

Leave a Reply

Your email address will not be published. Required fields are marked *

share on