Agile Scrum

Data by itself

by Ravi Chandra Reddy Gumma Starting way back in 90’s, the agile methodologies have overwhelmingly revolutionized the project management methodology over the due course of time. Unlike the earlier models (waterfall, v etc.), agile is more inclined towards adaptive rather than the predictive approach. Agile follows iterative – time bound cycles for development, testing and deployment whilst reducing standard heavy documentation. There are various methods which can be followed to implement agile methodology and the teams select a suitable method based on their project and environment.


Ken and Jeff created the scrum process in 1993 and the name scrum was influenced from the scrum of American football or rugby. It is a agile methodology framework of software development used to address complex adaptive problems.

In Scrum time is divided into short work cadences, known as sprints, typically two or three weeks long. At the end of each sprint, a shippable product is deployed.

The Agile scrum methodology follows a work breakdown structure. The whole product is broken down into smaller logical segments and worked on sections in an incremental fashion.

The work breakdown structure in scrum is as shown below:

Product is the whole shippable software that is in the scope of the project.

Epics are large sections of a project that have logically connected functionalities. An epic would accomplish one or more functionalities or features of a product. Each epic contains one or more user stories.

User stories are smaller pieces of work (a requirement) which is describes from a customer or user’s perspective. It is a high-level understanding of a small functionality. A user story contains one or more tasks.

Format of a user story- AS A <user>, I WANT <some goal>, SO THAT <some reason>.

Tasks are smallest broken-down pieces of work.

For example: In case of a website development. Whole website is the product. An Epic could be the home page. User story could be login functionality and a task could be username or password entry.


Scrum terminology:

The following are few common terminologies used in scrum.

Points– Story points are a quantitative value given to a user story based on the complexity and the estimated time it would take to complete. There are many ways a team gives the points, for example some use Fibonacci series (1, 2, 3, 5…) whereas some use t-shirt sizes (xs, s, m, l…) to quantify a user story.

Velocity- It is the measure of work that a team can handle within a sprint. It is either counted as the sum of story points the team has completed in a single sprint or the total hours the team spends in a single sprint.

Burndown chart- It’s a graphical representation of the work to be completed in a sprint (Y-axis) v/s the remaining time in the sprint(X-axis). The work done is generally measured in points and the time in days. It is used to asses if the sprint is on schedule and the comparison of work completed in actual and work planned. The graph goes down as the sprint progresses.

Burnup chart-This is like burndown chart but in the reverse fashion on the work done axis. Here the graph is between the work completed v/s the time remaining. The graph goes up as the sprint progresses.

Coherence- The reasonable level of inter dependency or connectivity among few user stories in a product backlog that could be considered to take up the respective user stories into a sprint together.

Definition of Done- A shared understanding of expectation from the end-product of a sprint to consider it releasable and moved to production. It is generally between the product owner and the development team.

Increment- It is a section of working software added to the previous increments. The addition of all the increments results in the whole software product.

Product backlog- It is the complete list of works to be done to meet all the system, project and product requirements. The list is articulated in a clear and sustainable way to deliver a viable product upon completion. The product backlog is ordered keeping in consideration the priority, business value, dependencies and risk. The product owner is the master for the product backlog.

Product backlog refinement- It is an exercise carried out by product owner and the sprint team to add granularity and re-order the product backlog items based on the requirements and the changing scenarios in the project.

Sprint backlog- It is the list of items to be pulled from product backlog to form a sprint. The items in the sprint backlog are pulled based on the priority, team velocity and the available team capacity for a sprint.

Sprint goal- It is a brief summary of the purpose of the sprint, often a business problem that is being solved during the sprint.

Scrum Board- It is a physical or virtual board which portrays the works to be accomplished within a sprint. The purpose is to keep all the items in sprint backlog visible to the team.


Core roles in Scrum:

 There are three major roles in scrum.

Product owner-This person is considered as the business champion and has a vision on the customer centric requirements of the project. The product owner is responsible for creating the items (typically user stories) of product backlog, prioritizing them and communicate to the sprint teams.

Scrum team-It is the team which does analysis, design, development, testing, etc. to deliver a shippable incremental piece of the product after every sprint. The team is generally a mix of analysts, architects, UI designers, software developers, QA experts and testers.

Scrum master- Scrum master is responsible to keep a check on the implementation of scrum processes and remove any impediments that block the team from achieving sprint goals. Scrum master also acts as liaison between the product owner and the scrum team.


Scrum Ceremonies:

There are four ceremonies that are followed in Scrum method:

Sprint planning- Sprint plan meetings are conducted to finalise the user stories from product backlog that would be part of the sprint. The user stories are picked based on the priority and the sprint velocity. The sprint plan is driven by the product owner.

Stand-up- It is a quick stand-up meeting conducted daily for about 15 minutes to keep a track on the status of sprint progress and identify any impediments. The scrum master drives the meeting with the scrum team to answer three major questions- what we did the day before?  what are we going to do today? And are there any issues/roadblocks?

Sprint review- It is held at the end of every sprint to demonstrate the functionality of feature that the team had developed during the sprint. The product owner and other important stakeholders review to check if the delivered piece of product has met the business requirements and provide feedback.

Sprint Retrospective- It is also held after the sprint ends. The scrum master and the team analyse the overall sprint performance and devises strategy for further improvement. The major questions answered are- what went well? What did not go well? And how do we improve?


Other well know methods in Agile:

Kanban – There are no core roles or time boxed iterations. The work is pulled through the system (single piece at a time) and completed leading to continuous delivery. Appropriate for high degree of priority variability projects.

XP (extreme programming) – It works on smaller iteration durations (1-2 weeks) and does have allowance for modification in plan in midst of the iteration. XP follows few mandated engineering practices like automated testing, refactoring etc.

FDD (Feature driven development) –

DSDM (Dynamic systems development method) – The work is broken down with fixed budget and time for each section. It follows 80-20 rule, 80% of the work is completed to meet the major business requirements and the rest if taken up in later stages.

Crystal –It is the most lightweight and adaptable methodology which comprises of multiple methods like crystal orange, crystal clear etc… The policies, practices and processes are tailored to meet the needs of different projects.

Leave a Reply

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