Explore topic-wise InterviewSolutions in .

Velocity is a measure of work done by the TEAM in a SPRINT. It is calculated at the end of the sprint by calculating total story points finished in that sprint.

For example – 

• If the team finished 20 story points in a sprint then the velocity is 20.
• It is a key feedback mechanism for the team. It is also a key metric in Scrum.
• It is recommended that stories which are incomplete or unfinished the credit to the points should not be given.

Velocity should be tracked throughout the sprint on the Sprint Burn Down chart and should be visible to all the team members. In case of the burn down is not proper Scrum Master and Product Owner can discuss with the team after daily stand up.

With velocity, the product owner can figure out how many sprints this product will the team TAKES to deliver the desired functionality and is ready to be shipped. Depending on the length of the sprint he can fix the release date of the product.

For an example, if the velocity of the team is 20 story points and total points estimated in the product backlog is 100 then the team is estimated to finish it in 5 iterations (2-week iteration then 10 weeks), in this way it helps in release planning.

It also FACILITATES how many stories can be finished in one sprint. Most of the sprint velocity keeps on oscillating but average velocity of past 3 sprints is a good measure.

In SCRUM, the team meets daily preferably in the morning time when a day starts and this meeting is called daily scrum. This is strictly time-boxed to 15 minutes. This keeps the discussion brisk and relevant. All team members are required to attend the meeting.

Scrum master is optional for the daily stand up.

This meeting should not be considered as a problem-solving meeting. Issues that are raised must be taken as offline right after scrum meetings with specific groups of people.

During the daily scrum each team member should answer the following 3 questions:

1. What did you do yesterday?
2. What will you do today?
3. Are there any impediments in your way?

By focusing on what each person ACCOMPLISHED yesterday and will accomplish today, the team gains an excellent UNDERSTANDING of what work has been done and what work remains. The daily scrum meeting is not a status update meeting in which a MANAGER is collecting information about who is behind schedule. Rather, it is a meeting in which team members make commitments to each other. By this meeting, the team gets an idea about where the sprint is heading towards...Behind the schedule or ahead.

Scrumban means combination of Scrum and Kanban methodology.

Scrumban is specially DESIGNED for project that requires frequent maintenance, having unexpected user stories and programming errors. Using these approaches, the team’s workflow is guided in a way that allows minimum completion time for each user story or programming error.

As in this approach we will not take up new task until the high PRIORITY task has reached the deploy state.

The below board depicts the above situation.

Let us compare Kanban and Scrum Approach.

Product Backlog:

• High level feature descriptions are gathers early but they are minimally described at that time and are progressively refined as the project progresses.
• It is a list of all desired functionality not yet in the product.
• It is maintained by the product owner and kept in priority order which is why it is also called as PRIORITIZED feature list.
• Unlike the traditional REQUIREMENTS a product backlog is highly dynamic, items are added, removed and reprioritized each sprint as it progresses and team learn more about product, the users and so on.
• Changes in business requirements, market CONDITIONS, or technology, cause changes in the Product Backlog, making it a live artifact.
• High ordered items are clearer than low ordered items.
• More precise estimates are made based on the greater clarity and increased detail.

Sprint Backlog:

• Sprint Backlog consists of selected items from the product backlog which has complete DETAILS and clarity of requirements and on top priority.
• Sprint Backlog is a FORECAST by the team that what all functionalities will be made available in the current sprint.
• The team modifies the sprint backlog as the sprint progresses which helps in tracking the sprint. Modifications includes tasking out the user stories.
• Whenever some task is completed it is moved to completed and when all the tasks related to one user story reached completion (Definition of Done) state then after sprint review this user story is moved to completion.
• Sprint Backlog depicts the real time picture which team decided to accomplish in a sprint and it is completely owned by the team.

Scrum defines only 3 roles-Scrum Master, Product owner and Development Team.

Scrum Master:

1. Removes the obstacles/impediments that impact productivity.
2. Shields the people from external disturbance.
3. Responsible if the scrum process is correctly applied .
4. Facilitate daily stand ups,other ceremonies ,SCHEDULE meetings,DEMO and other meetings
5. Help product owner in prioritizing the backlog and any feedback from the team.

Product Owner:

1. Ensuring that the Team understands items in the Product Backlog to the level needed to start the sprint or the development process.
2. Responsible for prioritizing the backlog.
3. Collaboration with stakeholders and customers.
4. Develop Release plan and release dates.
5. Provides vision to the team.

Development Team:

1. The team is self-organizing and cross functional. The team CONSISTS of Developers, testers, Devops, Architects, Tech leads, Analysts, Designers etc. Scrum team works closely with each other to build the product incrementally, maximizing feedback opportunities, build with good QUALITY. Incremental deliveries of a product ensure WORKING product is always ready at each increment.

During the DAILY Scrum MEETING one question should be about impediments, if any team member has any impediments, they should BRING it in front of team and team try to find out the solution. Most of the CASES team will only FIGURE out the solution but sometimes it is beyond the ability of the team then Scrum Master prime responsibility to listen, understand and remove the impediments.

Recurring impediments should be dealt in retrospectives where team brainstorm and try to find out the root cause of the problem and discuss about the solution.

Having no impediment is itself a big impediment.

Situation: When there are a lot of issues (Maintenance project or Ticketing project) from the field and the current project is team is handling both the things (current project and field issues) which methodology best suits.?

So, in my opinion the answer will be Scrumban (Scrum+Kanban) APPROACH. Because here requirements are changing so frequently which is hampering the current project and sprint.

Scrumban is specially designed for project that requires FREQUENT maintenance, having unexpected user stories and programming errors. Using these approaches, the team’s workflow is guided in a way that ALLOWS minimum completion time for each user story or programming error.

As in this approach we will not take up new task until the high PRIORITY task has reached the deploy state.

Few tips for selecting the PROCESS are:

1. Integrate workflows with a task list for better transparency. -Kanban
2. Scrum for continuously devotion to projects
3. Visualization of workflow-Kanban
4. Intense human collaboration and feedback-Scrum.

I feel there is always an OPPORTUNITY to improve. A retrospective is an opportunity for the team to inspect and create a plan to be enacted from the next sprint.

Retrospection is held after sprint review and just before the new sprint starts.This is will be a 1-hour meeting for a 2 weeks sprint, will extend in case of 4 weeks sprint. Scrum Master is the facilitator of this meeting and he should make sure Product Owner and ENTIRE team should attend this meeting.

During the Retrospective team DISCUSSES about the 3 things:

1. What went well in the sprint?
2. What could be improved?
3. What we should stop doing?

Scrum Master can ask everyone in the team to write at least 1 answer to each question an after that they can be discussed with the team. This is the opportunity for each team member to speak up and raise their voice against any decisions or issues.

Once we brainstormed the initial ideas, team will vote for any high priority ITEM to be focussed on during the sprint.

• Attendees: Development team, Scrum Master and Product Owner
• When: At the beginning of the sprint.
• Duration: Approx 4 HOURS for a 2-week iteration
• Purpose: Product owner COMES with the prioritized backlog and then the Scrum Team plans the items they are GOING to deliver in the Sprint and the way they will deliver them, estimate them, break into TASKS. The team can ask questions to the product owner about the user STORIES if they didn’t understand properly.

A nice feature of STORY points is that each team defines them as they fit. One team decide them as an ideal day of work (i.e. a day without any interruptions whatsoever-no MEETINGS, no email, no phone calls and so on.). Another team many define a story point as ideal week of work. Yet another team may define as a measure of complexity of the story. The most useful is estimating by complexity. For This we use one reference story and on the basis of that we estimate other user stories. Suppose if the user story is 5 points then and If any user story looks big or complex then reference story we estimate as 8 or more story points and if it looks less complex, we may estimate it as 3 or below story points.

A Story Point is a relative UNIT of measure, decided upon and used by individual Scrum teams, to PROVIDE broad brush relative estimates of effort for completing requirements stated in User Stories 

Story points further used to calculate the velocity of the sprint which is very helpful to predict the release dates.

Planning Poker:

• The below figure shows the poker cards available to estimate the user stories.
• Before starting Planning Poker, select one story which is a REFERENCE story (from the current backlog or that we have done earlier)
• In this technique team, Scrum Master, Product Owner will sit around the table (Figure shown below) for the planning poker session.
• Each team member will have a set of Planning Poker cards of values (0,.5,1,2,3,5,8,13,20,40 and 100) these represents story points in which team estimates.
• At the start of the session the product owner will READ the user story aloud, describing all its features and requirements.
• Then the team will estimate with the number mentioned on cards and show it to everyone. If all have given the same value then that will become the final estimate.
• If the values are different then estimators giving highest and lowest values explain their opinions and why these chose this value, until final consensus is reached.
• A good technique for small number of items in a small team
• Till the final consensus is reached team will have complete clarity on the user story.
• If the estimator doesn’t have any idea or couldn’t estimate can show (?) also.
• If the user story is ESTIMATED as above 20 considered as Epic which needs further BREAK down into smaller user stories.
• Story point estimated as 4 story points is of double the EFFORT, time and complexity then the story with 2 story points.

As per Scrum GUIDE it is recommended to have the scrum cycle or iteration for 2 weeks.But there is no rule, this can be purely adjusted to 2-4 weeks as per the team and project requirements.

How to DECIDE on iteration? —Check How to decide about the size of the iteration?

The roles defined by Scrum are:

1. Scrum Master-Servant leader between team and Product owner. Removes impediments for the team and always help them practice good agile practices.
2. Product Owner-Full CONTROL of the product. Key communicator between team and customer. Solves all queries regarding requirements and decide the PRIORITIZED backlog.
3. Development team-Team which works on requirements and built the potentially shippable product.

In addition to the above roles there are Product Management and stakeholders and CUSTOMERS are also involved during sprint reviews and providing feedback.

In the Scrum Guide the ROLE of Functional manager is not specifically defined. As scrum focuses more on the self-organization more of Functional Manager involvement is not required if they do so, then the team is not following the correct way of Scrum.

• Functional Managers usually retain the job of assigning individuals to projects. They will be expected to continue to make these decisions based on the competing needs and career aspirations of individuals, locations etc.
• In few organizations the role of a functional manager is accustomed to assigning roles to the individual which now after transition they will not be able to do that as an individual selection of work is a fundamental aspect of how the team self-organize and must be left with the team.
• They should now start working in the bottom-up approach. The manager should say “Here is our purpose and direction-I will guide and coach.”
• They also retain the responsibility for developing the people in their GROUPS. Securing the budget and time, encouraging them for innovations, challenging them, build the leader in them are all PARTS of the functional manager role.
• They also retain the role of HIRING and firing decisions which not even scrum master and product owner has this level of authority.
• Writing periodic reviews by taking the INPUTS from coworkers is also the prime responsibility of the functional manager and they will continue to retain them.
• They can also attend sprint reviews and even quarterly planning meetings.

Retrospection- After the Sprint Review, the Development Team holds an internal meeting to review the Sprint and use it to improve the process (lessons learned) in the next Sprint.

Also, find out what's not working and use the time to find creative solutions and develop an action plan. Scrum Master facilitates this meeting. We generally use sticky notes in which each team member writes three things about sprint (which just got over.)

1. What shall we continue?
2. What needs to be stopped?
3. What needs to be started?

Then the Team looks for underlying causes and agrees on one improvement for the following sprint with acceptance tests built in, along with a commitment to review the results at the next Sprint Retrospective.

Over the course of time, some Scrum practices begin to slip, or the meeting has become perfunctory, not effective.  Let’s look at how you got here through the frame of the usual suspects for an ineffective Retrospective.

The Usual Suspects are:

The whole team thinks it’s a waste of time.

If this is the case then ask the team why it is a waste of time? More likely the meeting is not managed effectively and the outcome of the meeting doesn’t lead to change in the action plan. Set the agenda of the meeting before it starts, and work towards it collectively.

Retrospectives aren’t valuable since we don’t have any impediments.

According to me, this is the biggest impediment like fear of conflict or lack of trust on team members.

 The Retrospective is just too hard.

Some team impediments are big.  Too big to solve in one meeting.  It’s important to make meaningful progress and keep the momentum going each Sprint, and this is most easily done by breaking down issues into something that can be ACCOMPLISHED and has a clear definition of done.

We do it but it doesn’t have an impact.

Scrum is there to help the team to deliver the products at a faster rate with a steady increase in velocity but if the flat-lined means retrospections are not able to find the root cause of it.

If the above conversations are true then the corrective actions need to be taken.

Adopt a new practice to REJUVENATE your Retrospectives.  Sometimes it’s as easy as changing the way the question is ASKED and the Happiness Metric is a great way to do that.  

The Happiness Metric is a simple tool used to FOCUS your Retrospective and collect actionable information.  It works like this:

Ask each Team member:

1. On a scale of 1-5, how happy are you with your role in the company?
2. On the same scale, how happy are you with the company?
3. What specifically increased your happiness last Sprint?
4. What specifically decreased your happiness last Sprint?
5. What would increase your happiness for the next Sprint?

By FOCUSING on your retrospective, you will increase velocity, finish early and accelerate faster. Try it, if it doesn’t work there will always be the next sprint.

Continuous improvement is what sustains and drives development within an agile team, and retrospectives are a key part of that.

Story points are a relative measure of the size of a user story. A user story estimated as ten story points is twice as big, complex or risky as a story estimated as five story points.

A ten-story point is similarly half as big, complex or risky as a twenty-story point story. What matters are relative values assigned to different stories. Velocity is also calculated by SUMMING the story point estimates for each completed story. Story points are purely an estimate of the size of the work to be performed. The duration of the project is not estimated as much as it is delivered by taking the total number of story points and DIVIDING it by the velocity of the team.

The most common way of estimating a User Story is by using Fibonacci series as it forces them to provide a relative estimate. It is easier for ANYONE to answer “Is that 5 or 8” RATHER than 6 or 7?

Testing is ITERATIVE and sprints based as DEPICTED in the diagram given below:

Pair PROGRAMMING the term derived from EXTREME Programming. Pair programming is a style of programming in which two programmers work side-by-side at one computer, sharing one screen, keyboard and mouse, continuously collaborating on the same DESIGN, algorithm, code or test.

One programmer, termed as the driver, has control of the keyboard/mouse and actively implements the code or WRITES a test. The other programmer, termed as the navigator, continuously observes the work of the driver to identify defects and also thinks strategically about the direction of the work.

When necessary, the two programmers brainstorm on any challenging problem. The two programmers periodically switch roles and work together as equals to develop software.

Pair programming is MUCH more effective as compared to code reviews. For code review, the code needs to be completed, but in programming in pairs leads to correct the code instantly without any waiting period. Pair programming is much more efficient as in code review it could be possible that the programmer might not be around. Fewer chances of bugs being corrected.

Benefits of Pair programming

• Fewer defects
• Better decisions
• Higher productivity
• Developers confidence
• Knowledge sharing
• Learning
• Team building

• When the same TEST case is to be repeated;
• When the test cases are very tedious and cannot be performed MANUALLY;
• If you have to run the test cases with different data and CONDITIONS SEVERAL times;
• When the same test cases are to be executed with different user sets;
• If saving time is on your top priority; or
• When test cases need to be executed with various BROWSERS and environments.

There have been continuous advancements in software development technologies. When talking about software development methods one can simply not ignore the role that testing plays in software development. Therefore, in order to maintain PACE with the latest software development technologies testing needs to be done faster than development.

Imagine you are building a big Software-as-a-Service product like Salesforce. The product has 1,000 features, and you also have to release a new feature EVERY other month to keep up with the competition. Now imagine that you have to test that product, check if new features have not AFFECTED old features and every feature is working fine. All 1000 of them. Now imagine that you have to test the whole software within a week.

Not possible, right? That’s what enterprise developers thought before automating the process of testing.

Sprint is generally for 2-3 weeks. In that case, to test the whole software is not easy so recommended way is to automation which drastically reduces the time of testing and every sprint delivers the BEST quality software.

SCRUM board is highly recommended in the DAILY scrum meeting.

It gives better VISIBILITY not only to the team but other stakeholders too. In case somebody missed the daily scrum, a meeting can quickly go through the scrum board and gather updates from there. It is recommended that scrum board not only has the data of the sprint progress but it should also have sprint burndown chart also so that the team will have updates on the health of the sprint. On top of the board, the Goal of the sprint should also be mentioned ALONG with the Definition of DONE list.

Definition of Ready: A SPRINT is a time-boxed development cycle in which items NEED to be pulled from the prioritized backlog. However, it is very important that the items (User Story) should be in “Ready state”. Pulling unfinished or unrefined user story will make the current sprint delay its deliverables as well as DEVELOPER will also not be able to develop the expected functionality.

“Ready” State is clearly depicted in the below diagram.

Definition of Ready is focused on the User Story level characteristics whereas Definition of Ready on Sprint and RELEASE level.

Definition of Done: It represents the acceptance criteria for the Sprint. This list is PREPARED in discussion/agreement with the Product Owner and Development team on what needs to be completed for user story—it is often standardized across the company in order to deliver consistent product quality.

Sample of Definition of Done is shown below. As per project needs, this can be tweaked.

• Test conditions are written where beneficial to a story
• Unit tests written (where crucial ) and passing
• Acceptance tests written, executed, and passing
• Functional testing complete
• System testing and bug fixing for functionality implemented
• Test cases are written and passing with expected results
• Regression tested where appropriate
• Code complete
• Code committed

Traditional waterfall model TREATS Analysis, Design, Coding and testing as discrete phases of a software project.

QUALITY Suffers:

First, the project runs out of money until it reached the last phase. This means that a good project tends to cut on the testing phase and the quality suffers.

Poor visibility:

Secondly, because working software isn't produced until the end of the project, you never really know where you are on a Waterfall project. That last 20% of the project always seems to TAKE 80% of the time.

Too risky:

Thirdly you've got schedule risk because you never know if you are GOING to make it until the end. You've got technical risk because you don't actually get to test your design or architecture until late in the project. And you've got product risk because don't even know if you are BUILDING the right until it's too late to make any changes.

Can’t make changes in the middle:

It’s not easy to make any changes in the middle because the architecture and all technical aspects are already closed before the development phase. It is very costly to do those changes in the middle.

The Agile Approach:

Instead of treating these fixed stages Agilists believe these are continuous activities.

By doing them continuously:

• Quality improves because testing starts from day one.
• Visibility improves because you are 1/2 way through the project when you have built 1/2 the features.
• Risk is reduced because you are getting feedback early, and
• Customers are happy because they can make changes without paying exorbitant costs.

The four values of Scrum as per the Scrum Guide are:

• Individuals and interactions over processes and tools

Valuing people more than the processes and tools is the main aim of Scrum. Communication is an example of valuing individuals versus process. It is the people who respond to business NEEDS and drive the development process. Daily Scrum meeting and Retrospection is an example of this where each individual will get to interact with the team and leaders directly.

• Working software over comprehensive documentation

Historically, an enormous amount of time is spent on documentation and was one of the biggest causes of DELAYS in product development and delivery which INDIRECTLY leads to customer dissatisfaction. It is a myth that Scrum doesn’t support documentation rather it streamlined the process in such a way which gives the developer an opportunity to work on what is needed and deliver the best quality software which leads to customer satisfaction. Agile documents REQUIREMENTS as user stories, which are sufficient for a software developer to begin the task of building a new function.

The Agile Manifesto values documentation, but it values working software more.

• Customer collaboration over contract negotiation

In the Scrum process, the customer has involved even before the project starts (Iteration planning), during the project execution which is sprint review. With this customer collaboration during the entire process, the development phase is quite easy and expected to meet the customer needs. With development models such as Waterfall, customers negotiate the requirements for the product, often in great detail, prior to any work starting which means that requirements are completely frozen and no scope of changing them in between.

• Responding to change over FOLLOWING a plan

With short sprint cycles, the customer change in requirements can be incorporated easily in the next iteration whereas traditional methods the incorporation of changes in the middle is very expensive.

Agile’ s view is that changes always improve a project; changes provide additional value.

BDD is an extension of TDD. The major DIFFERENCE between TDD and BDD are:

• Tests are written in plain descriptive English type grammar
• Tests are explained as the behavior of an application and are more user-focused
• Using examples to clarify requirements

This difference brings in the need to have a language which can define, in an understandable format.

Features of BDD

• Shifting from thinking in “tests” to thinking in “behavior”
• Collaboration between BUSINESS stakeholders, Business Analysts, QA Team and developers
• Ubiquitous language, it is easy to describe
• Driven by Business Value
• Extends Test Driven Development (TDD) by utilizing natural language that non-technical stakeholders can understand
• BDD frameworks such as Cucumber or JBehave are an enabler, acting as a “bridge” between Business & Technical Language

Example:

Scenario: Duplicate email Where someone tries to create an account for an email address that already exists.

Given I have chosen to sign up But I ENTER an email address that has already registered Then I should be told that the email is already registered And I should be offered the option to recover my password

Now after a look at the above example code, anybody can understand the workings of the test and what it is intended to do. It gives an unexpected powerful impact by enabling PEOPLE to visualize the system before it has been built. Any of the business users would read and understand the test and able to give you the feedback that whether it reflects their understanding of what the system should do, and it can even lead to thinking of other scenarios that need to be considered too.

Advantages of BDD:

• Writing BDD tests in an omnipresent language, a language structured around the domain model and widely used by all team members comprising of developers, testers, BAs, and customers.
• Connecting technical with nontechnical members of a software team.
• Allowing direct interaction with the developer’s code, but BDD tests are written in a language which can also be made out by business stakeholders.
•  Last but not least, acceptance tests can be executed automatically, while it is performed MANUALLY by business stakeholders.

TDD is defined as programming practice which starts before the development PHASE starts, unlike Traditional testing. It instructs developers to write new code only if an automated test has failed. The primary goal of TDD is to MAKE the code CLEARER, simple and bug-free.

TDD is an iterative development process. Each iteration starts with a set of tests written for a new piece of functionality. These tests are supposed to fail during the start of iteration as there will be no application code corresponding to the tests. In the next phase of the iteration, Application code is written with an intention to pass all the tests written EARLIER in the iteration. Once the application code is ready tests are run.

Any failures in the test run are marked and more Application code is written/re-factored to make these tests pass. Once application code is added/re-factored the tests are run again. This cycle keeps on happening until all the tests pass. Once all the tests pass, we can be sure that all the FEATURES for which tests were written have been developed.

Following steps define how to perform TDD test

• Add a test.
• Run all tests and see if any new test fails.
• Write some code.
• Run tests and Refactor code.
• Repeat.

Benefits of TDD

• The unit test proves that the code actually works
• Can drive the design of the program
• Refactoring allows improving the design of the code
• Low-Level regression test suite
• Test first reduce the cost of the bugs

• Epic -An epic captures a large body of work. It is essentially a large user story that can be broken down into a number of SMALLER stories. It may take SEVERAL SPRINTS to complete an epic. 
• User Story- A story or user story is a SOFTWARE system requirement that is expressed in a few short sentences, ideally using non-technical language. It is GENERALLY estimated in story points.
• Task- A task is a unit of work contained within a story. It is estimated in hours.

An example is given below.

• Sprint Planning Meeting: 
  • Attendees: Development team, SCRUM Master, and Product Owner
  • When: At the beginning of the sprint.
  • Duration: Approx 120 min for a 2-week iteration
  • Purpose: Product owner comes with the prioritized backlog and then the Scrum Team plans the ITEMS they are going to deliver in the Sprint and the way they will deliver them, estimate them, break into tasks.

There are two defined artifacts of sprint planning.

1. Sprint Goal-The sprint goal should be a short description of what the team plans to achieve during the sprint. It is written collaboratively by the team and the product owner.

Example-Implement login functionality of the website.

2. Sprint backlog-The sprint backlog is the output of the sprint planning. A sprint backlog is a list of the product backlog items the team commits to delivering plus the list of tasks necessary to delivering those product backlog items. Each task on the sprint backlog is ALSO usually estimated.

3. Iteration planning -Iteration is a more generic term with respect to the Agile. It is used for a single development cycle and is used for Iterative and Incremental process. Sprint is Scrum specific hence sprint is an iteration but not all forms of ITERATIONS are sprint.

One of the core principles of Scrum is working software over software documentation. But it doesn’t mean there will not be any documentation but yes, they need to keep at its minimum. It is more important to think about users’ goals than to list the attributes of a solution.

• In Scrum, we consider the requirements as User Stories. They are similar to the use case scenario. But use cases till tend to be larger than single story and can be more prone to containing embedded assumptions about user interface.
• Use cases are much more complete than user stories. Use cases are designed to be permanent artifacts of the development PROCESS while user stories are more transient and not intended to outlive the iteration in which they are developed.
• In the requirement documents use cases are written so that developers and customers can discuss them and agree to them. User stories are written to facilitate RELEASE planning and to serve as reminders to fill in requirements details with conversations.
• User stories emphasize verbal communication. Written LANGUAGE is often very imprecise, and there’s no guarantee that a customer and developer will interpret a statement in the same way.
• Traditional documents are very tiring, tedious, error prone and time consuming compared to user stories.
• In this case, time was wasted WRITING the three-fourths of the document that the team won't have time to develop, and more time will be wasted as the developers, analysts, and customer iterate over which FUNCTIONALITY can be developed in time. With stories, an estimate is associated with each story immediately. The customer knows the velocity of the team and the cost of each story.

Methodologies in the IT world means detailed, stringent, defined principles and mandatory processes and predefined ALGORITHMS. Every process or STEP should be carefully followed in sequence and documented properly.

Scrum is always MISUNDERSTOOD as a methodology rather it is a set of instructions given mainly for the product which has high uncertainties, complexities and unpredictable.

It is a process which works best for all the players emerges from the use of scrum and the boundaries are set by Scrum.

Scrum as a FRAMEWORK describes roles and rules upon principles that help and facilitate people in a low-prescriptive way.

The Scrum framework leaves different options and tactics to play the game as it replaces the defined algorithmic approach with respect to people and self-organization to deal with unpredictability and uncertainties issues. The Scrum core values give DIRECTION to the actions and the behavior of the Scrum team, and the additions they make to the framework.

One of the agile methodologies is Scrum which implements Agile principles.