Getting Started with Agile Scrum Methodology: The Complete Guide for Software Developers and Testers


This is the guide for software developers and testers to understand and start working on the very famous Agile SCRUM methodology for software development and testing. Learn the basic but important terminologies used in Agile Scrum process along with a real example of the complete process.

SCRUM is a process in agile methodology which is a combination of Iterative model and incremental model.

One of the major handicaps of the traditional water-fall model was that – until the first phase is complete, the application does not move to the other phase. And if by chance there are some changes in the later stage of the cycle, it becomes very challenging to implement those changes, as it would involve revisiting the earlier phases and redoing the changes.

Agile scrum testing

Some of the key characteristics of SCRUM include:

  • Self-organized and focused team
  • No huge requirement documents, rather have very precise and to the point stories.
  • Cross functional team works together as a single unit.
  • Close communication with the user representative to understand the features.
  • Has definite time line of max 1 month.
  • Instead of doing the entire “thing” at a time, Scrum does a little of everything at a given interval
  • Resources capability and availability are considered before committing any thing.

To understand this methodology well, it’s important to understand the key terminologies in SCRUM.

Also read => How to Deliver High Value Software Features in a Short Time Period using Agile Scrum Process

Important SCRUM Terminologies:

1. Scrum Team

Scrum team is a team comprising of 7 with + or – two members. These members are a mixture of competencies and comprise of developers, testers, data base people, support people etc. along with the product owner and a scrum master. All these members work together in close collaboration for a recursive and definite interval, to develop and implement the said features.

SCRUM team sitting arrangement plays a very important role in their interaction, they never sit in cubicles or cabins; but a huge table.

Scrum Team

2. Sprint

Sprint is a predefined interval or the time frame in which the work has to be completed and make it ready for review or ready for production deployment. This time box usually lies between 2 weeks to 1 month. In our day to day life when we say that we follow 1-month Sprint cycle, it simply means that we work for one month on the tasks and make it ready for review by the end of that month.

3. Product Owner

The product owner is the key stakeholder or the lead user of the application to be developed.

The product owner is the person who represents the customer side. He/she have the final authority and should always be available for the team. He/she should be reachable in case any one has any doubts that need clarification. It is important for the product owner to understand and not to assign any new requirement in the middle of the sprint or when the sprint has already started.

4. Scrum Master

Scrum Master is the facilitator of the scrum team. He/she make sure that the scrum team is productive and progressive. In case of any impediments, scrum master follows up and resolves them for the team. SCRUM Master is the mediator between the PO and the team. He / She keeps the PO informed about the progress of the Sprint. If there are any roadblocks or concerns for the team, discuss with the PO and get them resolved. Like team’s Daily Standup, a standup of the SCRUM Master with the PO happens every day.

Recommended read => How To Be a Good Team Mentor, Coach and a True Team-Defender in an Agile Testing World?

5. Business Analyst (BA)

A BA plays a very important role in SCRUM. This person is responsible for getting the requirement finalized and drafted in the requirement docs (based on which the user stories are created). If there are any ambiguities in User Stories / Acceptance criteria, he/she is the one approached by the technical (SCRUM) team who then takes it up to the PO else if possible resolves on his own. In large scale projects there may be more than 1 BA but in small scale projects, the SCRUM Master may be acting as the BA as well. It is a good practice to have a BA when a project kick starts.

6. User Story

User stories are nothing but the requirements or feature which has to be implemented. In scrum, we don’t have those huge requirements documents, rather the requirements are defined in a single paragraph, typically having the format as:

As a <User / type of user>
I want to <Some achievable goal / target>
To achieve <some result or reason of doing the thing>

For example:

As an Admin I want to have a password lock in case user enters incorrect password for consecutive 3 times to restrict unauthorized access.

There are some characteristics of user stories which should be adhered. The user stories should be short, realistic, could be estimated, complete, negotiable and testable. A user story is never altered or changed in the middle of the Sprint. It is the responsibility of the SCRUM Master and the BA (if applicable) to make sure that the PO has drafted the User Stories correct with the proper set of the Acceptance Criteria”. If any changes which will impact the sprint release are to be made, then such stories are pulled out of the sprint or they are done as per the hours available.

Every user story has an acceptance criterion which should be well defined and understood by the team. Acceptance criteria details down the user story provides the supported documents. It helps to further refine the user story. Anybody from the team can write down the acceptance criteria. Testing team base their test cases/conditions on these acceptance criteria.

7. Epics

Epics are equivocal user stories or we can say these are the user stories which are not defined and are kept for future sprints. Just try to relate it with life, imagine you are going for a vacation. Since you are going next week, you have everything in place like your hotel bookings, sightseeing, travelers check etc. But what about your vacation plan for next year? You have only a vague idea that you may go to XYZ place, but you have no detailed plan.

An Epic is just like you next year’s vacation plan, where you just know that you may want to go, but where, when, with whom, all these details you have no idea at this point of time.

In a similar way, there are features which required to be implemented in future whose details are not yet known. Mostly feature begins with an Epic and then broken down to stories which could be implemented.

8. Product Backlog

Product backlog is a kind of bucket or source where all the user stories are kept. This is maintained by the Product owner. Product backlog can be imagined as a wish list of the product owner who prioritizes it as per business needs. During planning meeting (see next section), one user story is taken from the product backlog, the team does the brainstorming, understands it and refine it and collectively decides which user stories to take, with the intervention of the product owner.

9. Sprint Backlog

Based on the priority, user stories are taken from the Product Backlog one at a time. The Scrum team brainstorms on it determines the feasibility and decides on the stories to work on a particular sprint. The collective list of all the user stories which the scrum team works on a particular sprint is called s Sprint backlog.

Sprint Backlog

10. Story Points:

Story points are quantitative indication of the complexity of a user story. Based on the story point, estimation and efforts for a story are determined. A story point is relative and is not absolute. To make sure that our estimate and efforts are correct, it’s important to check that the user stories are not big. Precise and smaller is the user story, accurate will be the estimation.

Each and every user story is assigned a story point based on the Fibonacci series (1, 2, 3, 5, 8, 13&21). Higher is the number, complex is the story.

To be precise

  • If you give 1 / 2 / 3 story point it means the story is small and of low complexity.
  • If you give points as 5 / 8, it is a medium complex and
  • 13 and 21 are highly complex.

Here complexity consists of both development plus testing effort

To decide a story point, brainstorming happens with in the scrum team and the team collectively decides a story point. It may happen that development team gives a story point of 3 to a particular story, because for them it may be 3 lines of code change, but testing team gives 8 story point because they feel this code change will affect larger modules so testing effort would be larger. Whatever story point you are giving, you have to justify it. So in this situation, brainstorming happens and the team collectively agrees to one story point.

Whenever you are deciding on a story point, keep the below factors in mind:

  • Dependency of the story with other application/module,
  • Skill set of the resource
  • Complexity of the story
  • Historical learning,
  • Acceptance criteria of the user story

If you are not aware of a particular story, don’t size it.
Whenever a story is = or > 8 points, it is broken down in 2 or more stories.

11. Burn down chart

Burn down chart is a graph which shows the estimated v/s actual effort of the scrum tasks.

It is a tracking mechanism by which for a particular sprint; day to day tasks are tracked to check whether the stories are progressing towards the completion of the committed story points or not.

Example: To understand this, check the below figure:

Burn Down chart 1

I have assumed:

  • 2 weeks Sprint ( 10 days)
  • 2 resources actual working on the sprint.

Story”-> Column shows the user stories taken for the sprint.

Task” -> Column shows the list of task associated with the user story.

Effort” -> Column shows the effort. Now; this measure is the total effort to complete the task. It does not depict the effort put in by any specific individual.

Day 1 – Day 10” -> – Column(s) shows the hours which are left to complete the story. Please see that the hour is NOT the hour which is already done BUT the hours which are still left.

Estimated Effort” -> is the total of the effort. For the “Start” it is simply the sum of the entire individual task: SUM (C5: C15)

A total number of effort that has to be completed in 1 day is 70 / 10 = 7. So at the end of day 1, the effort should reduce to 70 – 7 = 63. In a similar way, it is calculated for all the days till day 10, when estimated effort should be 0 (Row 16)


Actual Effort Left” -> as the name suggests, is the effort actually left to complete the story. It may also happen that the actual efforts increases or decreases then the estimated one.

You can use the in build functions and Chart in Excel to create this burn down chart.

Burn Down Chart steps would be:

  1. Enter all the stories ( Column A5 – A15)
  2. Enter all the Tasks ( Column B5 – B15)
  3. Enter the Days ( Day 1 – Day 10 )
  4. Enter the starting efforts (Sum the tasks C5 – C15 )
  5. Apply formula to calculate the “Estimated Efforts” for each day (Day 1 to Day 10). Enter the formula at D15 (C16-$C$16/10) and drag it for all the days.
  6. For each day, enter the actual efforts. Enter the formula at D17 (SUM (D5:D15)) for summing up the actual efforts left, and drag it for all the other days.
  7. Select it and create the chart as follows:

Burn Down chart 2

12. Velocity

A total number of story point which a scrum team archives in a sprint, is called Velocity. The Scrum team is judged or referenced by its velocity. Having said that, it should be kept in mind that the objective here is NOT achieving the maximum story points, but to have quality deliverable, respecting scrum team’s comfort level.

For example: For a particular sprint: total number of user stories are 8 having story points as

Scrum Velocity

So here the velocity will be the sum of the story points = 30

Definition of Done:

A Sprint is marked as Done when all the stories are completed, all dev, research, QA tasks are marked ‘Completed’, all bugs are fixed-closed else the ones that can be done later (like not completely related or are less important) are pulled out and added in the backlog, the code reviews and unit testing is completed, the estimated hours have met the actual hours put up in the tasks and most importantly a successful demo has been given to the PO and the stakeholders.

Activities done in SCRUM Methodology:

#1: Planning meeting

A planning meeting is the starting point of Sprint. It is the meeting where the entire scrum team gather, the SCRUM Master selects a user story based on the priority from the product back log and the team brain storms on it. Based on the discussion, the scrum team decides the complexity of the story and sizes it as per the Fibonacci series. The team identifies the tasks along with the efforts (in hours) which would be done to complete the implementation the user story.

Many a time planning meeting is preceded by a “Pre-Planning meeting”. It’s just like a home work which the scrum team does before they sit for the formal planning meet. The team tries to write down the dependencies or other factors which they would like to discuss in the planning meet.

#2: Execution of sprint tasks

As the name suggests, these are the actual work done by the scrum team to accomplish their task and take the user story into the “Done” state.

#3: Daily Standup

During the sprint cycle, every day the scrum team meets for, not more than 15 minutes (could be a stand up call, recommended to have during the beginning of the day) and state 3 points:

  1. What did the team member did yesterday
  2. What did the team member plan to do today
  3. Any impediments (roadblocks)

It is the Scrum master who facilitates this meeting. In case, any team member is facing any kind of difficulties, the scrum master follows up to get it resolved. In Standups, the board is also reviewed and it itself shows the progress of the team.

#4: Review meeting

At the end of every sprint cycle, the SCRUM team meets again and demonstrates implemented user stories to the product owner. The product owner may cross verify the stories as per its acceptance criteria. It’s again the responsibility of the Scrum master to preside over this meeting. Also in the SCRUM tool, the Sprint is closed and the tasks that are marked done.

#5: Retrospective meeting

The retrospective meeting happens after the review meeting. The SCRUM team meets and discusses & document the following points:

  • What went well during the Sprint (Best practices)
  • What did not went well in the Sprint
  • Lessons learnt
  • Action Items.

The Scrum team should continue to follow the best practice, ignore the “not best practices” and implement the lessons learned during the consequent sprints. The retrospective meeting helps to implement the continuous improvement of the SCRUM process.

How the Process is done? An example!

Having read about the technical jargons of SCRUM; let me try to demonstrate the whole process with an example.

Step #1: Let’s have a SCRUM team of 9 people comprising of 1 product owner, 1 Scrum master, 2 testers, 4 developers and 1 DBA.

Step #2: The Sprint is decided to follow 4 weeks cycle. So we have 1-month Sprint starting 5th June to 4th of July.

Step #3: The Product owner has the prioritized list of user stories in the product backlog.

Step #4: The team decides to meet on 4th June for the “Pre Planning” meeting.

  • The product owner takes 1 story from the product backlog, describes it and leaves it to the team to brainstorm on it.
  • The entire team discusses and communicates directly to the product owner to have clear understood of the user story.
  • In a similar way, various other user stories are taken. If possible team can go ahead and size the stories as well.

After all the discussion, Individual team member go back to their work stations and

  • Identify their individual tasks for each story.
  • Calculate the exact number of hours on which they will be working. How the member concludes these hours; let’s check that

Total number of working hours = 9
Minus 1 hour for break, minus 1 hour for meetings, minus 1 hour for mails, discussions, troubleshooting etc.
So the actual working hours = 6
A total number of working days during the Sprint = 21 days.
Total number of hours available = 21*6 = 126
The member is on leave for 2 days = 12 hours (This varies for each member, some may take leave and some may not.)
Number of actual hours = 126 – 12 = 114 hours.

This means that the member will actually available for 114 hours for this sprint. So he will break down his individual sprint task in such a way that total of 114 hours is reached.

Step #5: On 5th of June the entire Scrum team meets for the “Planning Meeting”.

  • Final verdict of the user story from the product backlog is done and the story is moved to the Sprint back log.
  • For each story, each team member declares their identified tasks, if required can have a discussion on those tasks, can size or resize it (remember the Fibonacci series!!).
  • The Scrum master or the team enter their individual tasks along with their hours for each story in a tool.
  • After all the stories are completed, Scrum master notes the initial Velocity and formally starts the Sprint.

Step #6: Once the Sprint has started, based on the tasks assigned, each team member starts working on those tasks.

Step #7: The team meets daily for 15 minutes and discusses 3 things:

  • What did they do yesterday?
  • What they plan to do today
  • Any impediments (roadblocks)?

Step #8: The scrum master tracks the progress on daily basis with the help of “Burn down chart”

Step #9: In case of any impediments, the Scrum master follows up to resolve those.

Step #10: On 4th July, the team meets again for the review meeting. A member demonstrates the implemented user story to the product owner.

Step #11: On 5th July, Team meets again for the Retrospective, where they discuss

  • What went well?
  • What did not went well
  • Action Items.

Step #12: On 6th July, Team again meets for the pre-planning meeting for the next sprint and the cycle continues.

(Click to enlarge image)

scrum agile methodology process

Tools that can be used for SCRUM activities:

There are many tools available which can be used extensively for tracking the scrum activities. Some of them include:


In the beginning, people may face some difficulty to adopt this methodology, but through practice, you will see SCRUM doing wonders. It keeps the resources very focused and you can actually see your application growing.

Many a time’s organization encourages team to have few hours as self-study and development as a scrum task and allocate few hours. During the review, team members also demonstrate what they have studied, and sometimes present any tool or application which they have developed. I personally appreciate this approach as it gives the people a chance to enhance their knowledge and also present their skills. (Well, I have learnt Selenium through this approach only! :) )


#1 Alecn

example is really useful. thanks for sharing.

#2 deepakshi

Thanks a lot for Explaining Scrum methodology in a easier way !!

#3 Dhana

Crystal clear and easy to understand . Great work , thanks.

#4 Sourabh


Can you provide test plan template for Agile project.


#5 Mahesh Sarje


Assigned to Agile project, had a day training for Agile. What a co incidence, its agile guide in front of me.

Thanks a lot

#6 Samba

The document is very much useful, thanks for sharing the document.

Thanks a Lot.

#7 Vamsi


It’s very good article and learn a lot from this article.


#8 Deep

Awesome explanation for Agile!
Thanks alot!

#9 Divya

A very informative article yet to the point. Thanks for sharing.

#10 Venu

Nice Article..Point to Point to article..

#11 ayushi

very nice….learn a lot .

#12 mehek

Very simple yet accurate .thanks for sharing.

#13 Shilpa Chatterjee - Roy

Thanks Everyone!!

I thought of writing on SCRUM because their were quite a few questions on SCRUM in the CTAL – Test Manager exam and it required some practical exposure to answer those. All those who are planning to take up the Test Manager exam, this will help them to solve the scrum related questions. In case of any doubt, please feel free to ask. I will be happy to answer :)

#14 raja ji

very useful …

#15 payal sharma

I am a newbie in QA Manual Testing but I want to learn the in and out of QA. Is this the right site for me? I have gone through the Agile Methodology. It is really wonderful. Please help me to study the in and out of QA. Thanks

#16 Rajahmix

Nice article I really enjoyed and benefited a lot from it, thank you

#17 Shilpa Chatterjee Roy


You are at the right place:)
This is the best site to learn and understand software testing. Just browse and go through this site and I bet you will learn a lot, from basic concepts to advance ones.

#18 Shobhit

Nice way of explaining the process. The graph and sheet really helped me alot.

#19 Subrato

Hi Shilpa,

I have a question, so what is the concept behind using the Fibonacci series? Why not any other estimation technique?


#20 Daniel F

Hello Shilpa

Thanks a lot for your post it has been very useful. Right now I’m looking to implement Agile on my place of work so I’m looking for techniques, steps or whatever help possible to easy up the adoption of it.

Appreciate your help with any suggestion.


#21 Murali

Hi Shipla,
A very informative tutorial to start up with.

#22 Hoa Mai

Hi Shipla,

This is the first article that I gain so much knowledge about the Agile. Moreover, it’s easy to understand and imagine where we are in Agile team.


#23 Hitesh Bhateja

Simple and Easy words used to Understand Scrum methodology…Keep up doing the same work.
(Thumbs Up)

#24 niranjan

Hi shilpa,
Can u explain why user story is assigned a story point based on the Fibonacci series (1, 2, 3, 5, 8, 13&21).

#25 Ashritha

Hi Shilpa,
This article has been very effective in providing me an insight on agile and its related concepts.
The idea has been elaborately explained with examples wherever required.

Thank you.

#26 arun


#27 Devi

Wow superb article .thanks for sharing

#28 sudheesh

Thanks for sharing this document, Its very useful. Well written, easy to grab. Thank you very much

#29 prasath

nice document

#30 prasath

nice document…..

#31 Vaibhav


#32 Vaibhav

What is this? you are running software testing website and the design issue is this you cannot handle. Please, resolve this issue.

#33 Swapna

In SoftwareTestingHelp , the info shared has an in depth glimpse to the practical head of things explained .Good work

#34 Mohammed Rashid

Very nice & adorable article..Great Work
Way of explanation is very effective.

#35 venkat

I am thankful for your Great article.
It is very very useful for me.

#36 Aruprasad

Very usefull to understand the concepts of AGILE

#37 Ratan

Its awesome :) thanks for the document

#38 Rithin

Very useful.. Nice article about Agile.. Worth Reading :)

#39 Vasanthi

Shilpa, you have done a great job in explaining Agile methodology in a very simple manner. This article helped me in refreshing my understanding of Agile. keep up the good work. Thanks

#40 Varsha

Great effort Shilpa, Very useful and easy to understand. Worth Reading.

#41 Sivaji

Hi Shilpa,

Thanks for giving Clear idea about agile, Its very useful information

#42 Akshaya

This article help me gain clear idea about Agile methodology.Thanks a lot

#43 Archana

Thanks for the detailed explanation about scrum

#44 Krunal soni

Really detailed and very well explained article I’ve ever seen about agile methodology.
Thanks a lot Shilpa.

But question arise in my mind
Why/how user story is assigned a story point based on the Fibonacci series?

Thank u

#45 Naveen

Simply understandable and thanks a lot .

#46 Neha

Thank you for sharing . It is interactive ,explained very well with the examples .

#47 prasad

nice explanation….better understanding for beginners.

#48 prashanthi

Nice explanation, it is really usefull.

#49 Vinil

Can you send Test Plan and test case template template for the Agile process…?

#50 shubhangi

I want to ask 1 question. if there are 5 team members a,b,c,d and e each of them working 6 hrs daily,but d works only 3hrs daily.B was on leave for 2 days.and sprint is for 2 weeks.then what will be the total no of hr in that sprint?

#51 Gaurav Sharma

Guys please answer my query (
Suppose I have a project of developing a Website in which I have to procure hardware, software, do installation, and then execution / coding / designing starts. So how will I make user stories for hardware / software procurement and installation? since these usually have dependencies on multiple vendors?
Second question- if I have to say integrate with a charging system and I have dependency on customer for the API access details, then how will I show dependency on customer in my user story? Say I have 5md estimate for API integration…but since I did not get the access details so those 5md were unused in the sprint. How such a situation is handled?
By the way, the description on this page about scrum / agile framework is awesome.

Gaurav Sharma

#52 suman

Awesome ………
good job mam…………

#53 kannaki

Great Explanation

#54 Pradeep

This post is really helpful to understand the basics and depth of Agile methodology. Each point is explained well….

#55 phani

Very nice !! and informative explanation. All in one simple but yet detialed info for everyone.
Can you add Time-box plan and Product Raodmap to the Article.

#56 RockDogg

Yaba Daba Do!!

#57 Pradeep

Thank you writing such a simple and clear steps on agile development.
I am in learning scrum and following all your steps.
Helping me a lot.

#58 Divya A

Very Very good article.
Thank You!

#59 Ravi

Very well explained. Thanks.

#60 Smita Agrawal

really very useful article, very well explained…great work.

#61 KastorTroy

Nice job, but you mentioned that user stories should be sized using fibonacci numbers, but in the Burn Down Chart if I sum the 3 tasks of the user story 1, column Start; the total is 8+6+3 = 17, and that’s not a fibonacci number. I don’t understand

#62 Ofelia

Very good this article gave me a clear idea about Agile methodology.Thanks a million

#63 Piyush

Very well explained..Must read article on Agile

#64 sapan

Nice document for easy to understand

#65 Divya Mishra

The article is very informative and it helped me a lot in understanding the Agile flow and process.

Can you please explain in more details- Burn up & Burn Down chart with examples.

Thanks a lot dear :)

#66 Simone

Great job! Thank you very much for the simplicity of the language. It goes straight in the head!

#67 Omkar

Thank you so much for this informative page. Keep up the good work.

#68 Rajat kachhwaha

Thanks and Regards

#69 Arvind Ligade

Very very nice and useful.

Thanks a lot Shilpa for your valuable efforts…!!!!

#70 Ashima

Very helpful article.. easy to understand

#71 Karthikeyan

One question,When will the grooming meeting occurs?

#72 paul

Interesting and bang on.

#73 Asraful

worth reading and well mapped to practical scenarios

#74 Himanshi

Thanks for sharing the article.. Worth reading the same, practical scenarios with examples helped a lot in understanding a clear picture

#75 Suganyalatha

Well explained. Good article for beginners. Worth out of reading.

#76 Snehal Rathod

Thank you so much for sharing great artical…

#77 Venkatesh


#78 sowmya

Really helpful, thanks for sharing.

#79 rashmi

Thanks for sharing this information.. I was seriously looking out for such detailed really helps me a lot for understanding about agile

#80 varun k

Hi, Nice article. Can you explain other models of Agile methodology in the same way

#81 Shilpa Chatterjee Roy

Many of you have asked, why use Fibonacci series? Well in Fibonacci series, the next number is 60% more than the previous number so it helps to relatively estimate and size a story.

#82 Anurag Singh

Thank you so much for this great explanation in this article.

#83 Datta

Nice artical…

#84 Usha

Putup very well. Good article

#85 Mayur

Nice article , gives clear understanding of process. Good work.

#86 John

Nice very useful and easily understandable

Leave a Comment