Java-Success Blog: Agile software development methodology questions and answers

Agile Development Interview Questions and Answers

More and more organizations are becoming agile, and it pays to have some understanding of the agile development methodology.

Q. What are the typical roles and responsibilities of an agile core team?
A.

The Product Owner represents the stakeholders and is the voice of the customer. He or she is accountable for ensuring that the team delivers value to the business. The Product owner writes typically the user stories, prioritizes them, and adds them to the product backlog. Scrum teams should have one Product Owner.
The Development Team is responsible for delivering potentially shippable product in increments at the end of each Sprint. A Development Team is made up of 3–9 people with cross-functional skills who do the actual work (analyze, design, develop, test, technical communication, document, etc.). The development team consisting of developers, testers, operations staff, etc define the definition of "Done", which includes non-functional requirements like security, performance, cross browser compatibility testing, etc. Generally, you will have the doers and the helpers in the development team. The Development Team in Scrum is self-organizing, even though they may interface with project management organizations (PMOs).
Scrum Master Scrum is a facilitator, and is accountable for removing impediments to the ability of the team to deliver the sprint goal/deliverables. The Scrum Master is not the team leader, but acts as a buffer between the team and any distracting influences. The Scrum Master ensures that the Scrum process is used as intended. The Scrum Master is the enforcer of rules. A product manager cannot be the scrum master.

Q. What do you understand by the terms epic and user story?
A. An agile Epic is a group of related user stories. For example, an online shopping cart app will have epics like user administration, product management, and shopping experience. An epic will have a number of broken down user stories. For example, the "user administration" epic can be broken down into user stories like "add. modify, and delete user", "manage user passwords", "generate raw data downloads", "generate aesthetically pleasing reports", etc. Hence, a user story is an Independent, Negotiable, Valuable, Estimatable, Small, Testable requirement (“INVEST Acronym”). User stories are great for Development Teams and Product Managers as they are easy to understand, discuss and prioritize – they are more commonly used at sprint level on the wall. User stories will often be broken down into tasks during the Sprint Planning Process – that is unless the stories are small enough to consume on their own.

So, an epic will have one to many user stories, and each user story can have zero to many tasks.

Q. Can you given an example of a user story?
A. The user stories are in the format of

"As Who I want What so that Why"

Here is an example.

"As an Investment Manager I want to be able to view client account balances, so that I can make informed investment decisions. "

"As a support staff I want the system to allow me run multiple searches at the same time, so that I can do my job faster. "

Q. What do you understand by the term "Condition Of Satisfaction (aka COS)"?
A. For each story, the business user, analyst, owner, or stake holder will define the "condition of satisfaction (COS)" criteria to satisfy that particular story. You can also think of it as an "acceptance criteria". A Conditions of Satisfaction questions the User Story, and encourages conversation between the Product Owner and the team. A good way of gathering COS is asking questions such as:

    •    ‘What if … ?’,
    •    ‘Where …?’,
    •    ‘When …?’,
    •    ‘How …?’.

The test cases will be written by the testers and development tasks will be carried out by the developers to satisfy the COS. To be accepted, the development task should also satisfy other non functional tasks like writing unit tests, continuous integration and build, security, performance, data archival, etc. The story will also have to be fully tested. For example, COS will look like

A search functionality to be able to search clients by client code.
Display the client list sorted in alphabetical order.
Ability to click on a particular client to display his or her account balances.
The account balances need to be sorted by account type.
....and so on including non functional requirements as well.

Q. How do you estimate development and testing effort of a user story?
A. Agile projects normally have a number of sprints to finish the user stories. Each sprint will be of 2-3 weeks. One or more user stories are allocated to each sprint. The developers and testers will estimate on it to have story developed and fully tested to satisfy the COS. If a story is big enough so that cannot be completed within a sprint (i.e. in 2 weeks), that particular sub story can be split further into 2 or more stories.

The stories are estimated by allocating points. It is known as the "velocity points". The velocity points are allocated to each story. Stories are tagged like T-shirt sizes -- Small, Medium, Large, and Extra Large, etc. Each of these sizes are allocated velocity points using the Fibonacci series values. For example, 3, 5, 8 and 13. Where Small is given 3 points, Medium is given 5 points, Large is given 8 points, and extra large is given 13 points. A the end of each sprint, the velocity points for all the user stories are added and reported to the management in a "showcase" to monitor progress. The points play(i.e. the user stories that are not completed within this sprint) that are added to the next sprint.

In the diagram above, you can see "commitment" and the "completed".

Q. What are some of the key featues and objectives of the daily stand-ups?
A.

Daily Stand-ups are named literally after the way the meeting is conduced -- i.e. while standing up. This method helps ensure the meetings remain time-boxed to 15 minutes and not dragged on.

The general features are:

It is a ritual that happens at the same time, in the same location, every day.
The meeting is led by the Scrum Master, who keeps all attendees focused on answering the following key questions to meet the project objectives.