Are you a job seeker who is looking to find out some quick ways to crack an Agile interview? Spend some time every day to master the top Agile interview questions. These agile interview questions will help you demonstrate your knowledge of Agile. This ultimate list of agile coach interview questions will help you answer questions on Burn-down charts, Burn-up charts, User stories, Scrum of Scrum, etc. These Agile interview questions and answers can be the gateway to your dream jobs as a Agile Developer, Agile Coach.
These charts help to keep the track of the sprint progress. Burn up charts indicates the amount of work completed in the sprint and the burndown chart indicates the amount of work remaining in the sprint.
The Product Owner determines the amount of remaining work and compares it to the remaining work of the previous Sprints and forecasts the completion date of the project.
In the Burn-Down chart, the vertical axis (remaining work) shows the amount of work (which is a sum of all the estimates for each item in the Product Backlog), and the horizontal axis shows the amount of time passed from the beginning of the project or the number of Sprints passed.
We usually add another line to present the uniform distribution of the volume of the work across the initially estimated number of sprints. This line acts as our planned progress and will be used to compare to our actual values.
In the above chart, we can expect the project to be completed earlier than initially planned.
In the Burn-Up chart the vertical axis represents the amount of work and is measured in units or story points, and the horizontal axis represents time, usually measured in days.
On each day you can see the amount of work completed and the total amount of work. The distance between the two lines is thus the amount of work remaining. When the two lines meet, the project will be completed. This is a powerful measure of how close you are to the completion of the project.
Agile Estimation techniques:
1) Planning Poker:
2) T-Shirt Sizes:
3) Dot Voting:
4) Bucket System
Story points are helpful because they allow team members who perform at different speeds to communicate and estimate collaboratively.
When story points equated to hours, team members can no longer do this, as the time taken by one person compared to another person is different. One can finish the task in 3 hours and the other in 6 hours. Our aim is to estimate the user story, not to deep dive into why one person took 3 and another 6. If someone instructs team members that one point is equal to 8 hours, the benefits of estimating in an abstract but relatively meaningful unit like story points are lost.
Suppose for some reason you have tracked how long every one-story-point story took to develop for a given team. If you graphed that data you would have something that would look like this:
This shows that some stories took more time than others and some stories took less time, but overall the amount of time spent on your one-point stories takes on the shape of the familiar normal distribution.
Instead of looking at a User Story and estimating it in hours, teams consider only how much effort a User Story will require, relative to other User Stories.
“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.
The most common way of estimating a User Story is by using the 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?
There are 4 ceremonies in Scrum process.
Other than that, there is a Product Backlog Refinement meeting.
The backlog grooming meeting is attended by the team, the Product Owner, and the Scrum Master. During the meeting, everyone works together to prepare the backlog for the next sprint planning meeting. This might include adding new stories and epics, extracting stories from existing epics, and estimating effort for existing stories
Attendees: Development team, Scrum Master, 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, and break them into tasks.
Attendees: Development team, Scrum Master, Product Owner
When: Once per day preferably in the morning.
Duration: 15 min
Purpose: The Development Team starts working on the objectives of the Sprint as soon as Sprint Planning is completed. During the Sprint, the Development Team holds a daily meeting (normally 15 minutes) to coordinate the work for the next 24 hours. This meeting is called the Daily Scrum.
Have each team member answer the following questions:
What did I complete yesterday?
What will I work on today?
Am I blocked by anything?
Do not discuss any technical details and issues in detail. You can do that right after Daily Scrum with the chosen members only.
Attendees: Development team, Scrum Master, Product Owner
When: At the end of the sprint.
Duration: 30 -60 minutes
Purpose: Before the end of the Sprint, the Development Team presents (demonstrates) the outcome of the Sprint to the customer and receives feedback. This meeting is called the Sprint Review (also known as Sprint Demo). Remember, work should be fully demonstrable and meet the team's quality bar to be considered complete and ready to showcase in the review.
Attendees: Development team, Scrum Master, Product Owner(optional)
When: At the end of an iteration
Duration: 30 -60 minutes
Purpose: 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.)
Then the Scrum Master discusses the issues (without specifying anyone’s name) and develops the action plan.
Continuous improvement is what sustains and drives development within an agile team, and retrospectives are a key part of that.
A very good and practical question. There is no perfect answer to this question as different projects have different requirements, and release and deadlines are already set. It generally disrupts the team momentum and creates chaotic.
Ideally, the new requirement needs to be added in the next sprint as current sprint is already frozen. Product owner also knows about this. So, he/she should add this to the next sprint and prioritize the backlog again. But, if the product owner is coming in between and asking us to add this and work on it, it means either of the following:
In most of the cases, the new requirement in discussion with the product owner and the customer can be added to the backlog and taken up in the next sprint.
But, if this is not possible then there are two ways to handle this:
Having said adjusting new requirement in the current sprint is just an exception, not a norm.
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.
A sample of Definition of Done is shown below. As per project needs, this can be tweaked.
By asking this question interviewer wants to check your knowledge on Agile testing.
Testing is not a separate phase and carried out with as part of the iteration
Testing is a separate phase and carried out once the development is done.
Testers and developers work together
Tester work separately with developers
Testers are involved from the requirement phase so that they will be able to write the test plan and acceptance criteria. Also, Logical Acceptance test cases would be ready along with requirements
Testers are not involved in the requirement phase.
Acceptance testing is done in each iteration and customer feedback is taken
Acceptance testing is done at the end of the project
Every iteration completes its own testing thus allowing regression testing also in each iteration in case of release of any new logic or functionality
Regression testing is done at the end of the development phase.
Continuous testing with test levels overlap
Testing is a timed activity and test levels cannot overlap
The entire team is responsible for the testing activity
Test Lead or Project manager leads this phase
Client involvement is needed throughout the phase
Client involvement is needed only at the requirement phase only.
The other commonly used Agile Testing Methodologies are−
Test-Driven Development (TDD) − Test-Driven Development (TDD) is based on coding guided by tests.
Acceptance Test-Driven Development (ATDD) − Acceptance Test-Driven Development (ATDD) is based on communication between the customers, developers, and testers and driven by pre-defined Acceptance Criteria and Acceptance Test Cases.
Behavior-Driven Development (BDD) − In Behavior-Driven Development (BDD) testing is based on the expected behavior of the software being developed.
This term generally comes from the SAFe context when there are 5-10 Scrum Teams (Geographically distributed). In that case, each team designates one “ambassador” mostly Scrum Master to participate in the weekly/daily meetings with ambassadors of other team called Scrum of Scrums (SoS). The RTE (Release Train Engineer) facilitates this meeting and agenda is to update the progress towards milestones and PI objectives and manage inter-team dependencies.
The Agile Manifesto lays out values that help teams get into an Agile mindset. When everyone on the team genuinely incorporates these values into the way they think, it helps them build better software.
Following are the Agile Manifesto –
Individuals and interactions over processes and tools: While Agile team value processes and tools as it helps the team get organized and work effectively, they value people and interactions more because teams work best when they are self-organized, motivated, co-located and pay attention to the human element.
Working software over comprehensive documentation: While Agile team values comprehensive documentation because it’s an effective way to communicate complex requirements and ideas, they value working software more because it’s the most effective way to communicate progress, understand evolving requirements and get feedback from users.
Customer collaboration over contract negotiation: While Agile team values contract negotiation because sometimes it’s the only way to work effectively in an office culture where mistakes are punished, they value customer collaboration more because it is much more effective to get proper production requirement for building software.
Responding to change over following a plan: While Agile team value following a plan because, without planning, complex software projects go off the rail, they value responding to change more because the team that works on the wrong plan ends up building the wrong software.
While there is value in the manifesto items on the right, the Agile team values the items on the left more. A Scrum team is like a family where each person has different roles. A Scrum Master's role is one where the person focuses on removing the impediments and is also the process champion. Hence, a Scrum Master helps the team get more organized and work effectively by adopting some best practices and processes. Having said that, Scrum Master’s primary responsibility is to help the team be more successful.
While it’s natural to resist a big change, if a team can find a way to not just accept but welcome these changes, it means that they’re putting the users’ long-term needs ahead of their own short-term annoyance. In a context which is dynamic, one cannot specify and plan in detail because the context changes before one can deliver. In such a case, continuing to deliver as per plan will lead to low staff motivation due to a failed project and lost opportunity due to an unsatisfied customer. Responding to change is not only more effective, but it is also imperative for companies that must compete in a fast-paced, cutthroat, rapidly changing marketplace. Scrum responds to changes between sprints but still follows a plan during sprints. That’s why we value responding to change *over* following a plan, not *instead* of.
Agile testing principles complement general Agile principles and are as below:
Simply expressed, velocity is the amount of work that a team can get done in a fixed timeframe. It indicates the average amount of Product Increment created during a Sprint by a Scrum Team. A Sprint Burn-down Chart is a helpful tool is used by the Scrum Team to maintain and share information about the team’s velocity. While a Team's velocity will vary each sprint, over time, a well-functioning Scrum Team's velocity should steadily trend upward each Sprint. With the knowledge of team velocity, a Product Owner can project on how many sprints are required for the team to deliver the desired level of functionality that can be released. Since different teams may have different approaches to estimation, we should avoid comparing velocity between teams.
Burn down and burn up charts are two types of charts that scrum team use to track and communicate the progress of their projects. A burndown chart shows how much work is remaining to be done in the project, whereas a burn up shows how much work has been completed, and the total amount of work.
As the progress is measured independently on scope change, the burn-up chart makes progress perfectly visible.
So, the mechanics are basically the same. The only difference is that instead of tracking how much work is left to be done, it tracks how much work is completed, so the curve is going up, not down.
Contrary to popular believes that Sprint Zero is necessary because there is some groundwork that needs to be done before a Scrum project can start (for example, a team needs to be assembled, a hardware to acquire or at least set up, an initial product backlog is to be written), it is used to create a minimal design so that a detailed design can emerge incrementally in an efficient way in future sprints.
Potentially shippable act as a reminder that the developed features may not be sufficient enough to be truly shippable. While each organization or team establishes an appropriate Definition of Done for its context, there are certain guidelines that are applicable across most Scrum projects.
The ability for a team to be cross-functional is fundamental to all agile methodologies. A cross-functional team should be balanced on technical skill levels and domain knowledge should be diverse and persistent. The team structure should reflect that of a feature team who can better evaluate the impact of design decisions. A cross-functional team need to be balanced between being too generalists and being to specialists and it does not require any specific role.
As per Agile Manifesto Principle 6, “The most efficient and effective method of conveying information to and within a development team is via face-to-face conversation”. To encourage this rich form of communication, a user story card is intentionally kept as brief as possible and has 3 elements:
Card: The user story card includes just enough text to identify the story because the card is simply a token that represents the requirement for the planning process.
Conversation: The details of the story are communicated via a conversation – a verbal exchange of ideas, opinions, and information between the customer and the development team.
Confirmation: This means that the product increment passes the customer’s acceptance test and meets the agreed upon definition of “done”.
To build a good user story, Bill Wake described six characteristics of a good user story –
Independent: Ideally, our goal is to be able to reprioritize and develop our user stories in any order. And this can be achieved, though hard, by creating independent user stories that can be selected on merit, rather than dragging into the release because other user stories depend on it.
Negotiable: The team should be able to discuss user stories with the product owner and make trade-offs based on cost and function. Negotiating user stories leads to an improved understanding of the true requirements, costs, and acceptable compromises.
Valuable: User stories without clearly understood business benefits will be difficult to prioritize, since backlogs are usually ranked in business value. And if we cannot determine the value of a requirement, then we should question why it is a part of the project.
Estimable: Estimation is required to prioritize work based on its cost-benefit trade-off.
Small: Small user stories are easier to estimate and test than large user stories.
Testable: Having testable user stories is important for tracking progress because agile teams often measure their progress based upon the number of stories that have been successfully accepted.
The best approach for estimating user stories is one that-
Agile teams rely on collective problem solving rather than individual ingenuity because problems are solved more quickly and effectively when diverse viewpoints are brought to bear, rather than when team members try to push through their own. And although it is the Scrum Master’s role to remove impediments to progress, that refers to eternal roadblocks. When it comes to development issues, in many cases only the team members have the expertise needed to resolve the issues.
Agile models are lightweight, barely sufficient models that aim to capture the high-value benefits of modeling without taking too much time to create very detailed or polished models. We want to focus on the product being developed, rather than on generating documentation.
The most popular agile models include: Scrum, Lean and Kanban, XP, DSDM, and FDD.
Iteration planning begins with a meeting that includes the delivery team, the product owner, and possibly other stakeholders or SMEs as needed.
In the first half of the meeting, the product owner describes the backlog items they’d like to see developed in the sprint, and based on that, the team members select a set of items that they think are achievable.
In the second half of the meeting, the team breaks down the selected backlog items into the smallest unit of work to come up with a list of action items for the iteration.
In summary, we need to accomplish the below steps during the iteration planning process –
This is a very good interview question. And the expectation of the interviewer is that you should have a clear understanding of Waterfall and Agile.
So, the answer is “NO”. Both approaches have their own strengths and weakness, so it all depends on the type of project and its environment. Both have effective planning, execution and controlling.
Below table clearly defines the scenarios, when to use Scrum to achieve better results.
|When to use SCRUM||When to use Waterfall (Traditional Method)|
|Scope not clearly defined.||The scope is clearly defined upfront|
|Requirements changes frequently||Requirements are well defined|
|The Project is complex and unpredictable||The Project is simple and predictable|
|Incremental results have value and can be used by users (Production)||The Product cannot be used unless it reached its milestone|
|Customer available||Customer may or may not be there.|
Scrum is not a prescriptive method, but a suggestive approach to software development. So, the way it is implemented makes all the difference.
Then the interviewer may give you one case study and ask you to find which will be the best Methodology.
Situation: When there are a lot of issues (Maintenance project or Ticketing project) from the field and the current project team is handling both the things (current project and field issues) which methodology best suits?
The Interviewer is expecting the knowledge of Kanban and Scrum both.
So, in my opinion, the answer will be the Scrumban (Scrum+Kanban) approach. Because here requirements are changing so frequently which is hampering the current project and sprint.
Scrumban is specially designed for a project that requires frequent maintenance, having unexpected user stories and programming errors. Using this approach, 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 a new task until the high priority task has reached the deployed state.
The below board depicts the above situation.
The intention behind this question is to indirectly ask the responsibilities of the Scrum Master or a leader. He is expecting the real-time experience which you have faced.
Every team will go through 4 stages of group development which is Forming, Storming, Norming, and Performing.
Most team members are new, polite and humble at this stage also the roles and responsibilities are not clear to the team.
Storming can also happen in other situations. Example: Team members may challenge your authority, or jockey for position as their roles are clarified. Or, if you haven't defined clearly how the team will work, people may feel overwhelmed by their workload, or they could be uncomfortable with the approach you're using. This is the situation where many teams fail.
This is when people start to resolve their differences, appreciate colleagues' strengths, and respect your authority as a leader.
The team reaches the performing stage, when hard work leads, without friction, to the achievement of the team's goal. The structures and processes that you have set up support this well.
As a leader, you can delegate much of your work, and you can concentrate on developing team members.
The same is depicted in the figure below.
As a leader, we should handle this situation very diligently. My approach could be:
In SCRUM approach User Story is used as a requirement. The best way to write the user story is “As a ___, I want___ so that I can ___.”
Example: As a user, I want to login to the screen so that I can book the tickets.
The test for determining whether or not a story is well understood and ready for the team to begin working on it is the INVEST acronym:
I – Independent
N – Negotiable
V – Valuable
E – Estimable
S – Small
T – Testable
This is a very common scenario seen in the projects which are using Scrum Approach. The team should always be prepared for that. But try to have a good conversation with the Product owner to not include in the current sprint and deferred to the next sprint. Changes in requirements sometimes taken as a feedback from the customer so that the product can be improved. We should be ready to embrace this change.
As a tester, they should take the generic approach by writing the generic test cases (Login screen, user credentials). Till the requirements are stable, try to wait if you are planning to automate the test cases.
As a developer same approach can be used where chances of changes are minimal. Try to code using design patterns and oops concepts (Components or package independent of each other), so that change in one component make minimal changes in another.
A very good interview question for an experienced person.
Make sure the board is right in front of a team where the daily meeting is held.
In simplest terms velocity is the sum of story points completed in one sprint. From my perspective, velocity is like other metrics of the scrum which should be used for planning purposes i.e. how many user stories can be incorporated for any release or sprint. Velocity should remain constant if the team conditions remain the same. If there is any change with respect to the team, the change in velocity is also expected.
But, how to calculate the team’s first velocity during planning.
The general rule is to plan one-third of the capacity of the total team members.
Example: If there are 6 programmers and 2 weeks iteration then there will be 60 programmer days, one-third of this will be 20 story points which we need to plan. As this is a new sprint and a new team, it will take some time to stabilize. And also some time may be for meetings, emails, designs etc.
The second way is to take the history of the team progress in other projects. (Condition-If the team is the same or at least have the same skill set and worked on a similar project before.)
Also, remember that velocity will quickly emerge during the first iteration. If underestimated, velocity in the first iteration will rise as new features are included; and if overestimated, velocity will decrease as features are removed. For the second iteration, the Scrum team should then use the first iteration as a guideline.
The graph shown below shows different velocities in different sprints. If we take the average velocity (Green line) then it comes out to be 13 story points.
“Velocity is more of a quantity of work completed metric. Useful and important, but not the sole measure of success. I think you would want a set of metrics that together help us understand our current capabilities to deliver as well as if those capabilities are changing from one point in time to another. I don't believe there is one magic "agility number" to measure [productivity].”- Paul Hodgetts, Agile Coach
Which is important because according to the Agile Manifesto, “Working software is the primary measure of progress.”
A very practical question. I have seen this happening in most of the projects where I worked. There are multiple reasons for not completing the user story example-Dependencies, waiting for some inputs, defects found, some unplanned work, team member went on unplanned leaves, not estimated properly etc.
As a Product Owner we can handle this in below-mentioned ways:
The User Stories which are not completed can be transferred to the next sprint.
The tasks which are completed for this user story can be closed. We can re-estimate the story again in the next sprint and take this story as a high priority in the next sprint.
But the question arises Does the team earns the velocity credit?
If we are deferring the unfinished user story to the next sprint then do not take the velocity credit for it. Let the user story meets its acceptance criteria and then take the complete credit in the next sprint. We already know that we use average velocity, this averages out and avoid the risk of overstating velocity.
But in case of splitting the user story then take the credit of points burned for the work completed and let the remaining points for the unfinished work in the next sprint. This just boosts up the team’s morale as they have been given the points for the work completed and efforts they have put in.
I am a bit reluctant in taking this decision. Take your call based on discussion.
SAFe (Scaled Agile framework) helps businesses address the significant challenges of developing and delivering enterprise-class software and systems in the shortest sustainable lead time.
When to use SAFe:
The benefits of SAFe are:
Its principles are shown in the diagram below:
Another agile methodology is Kanban, XP (Extreme Engineering, Lean thinking).
Let us compare the Kanban and Scrum Approach.
|Limit your (WIP) PER ITERATION||Limit your (WIP) PER ITERATION|
|Prescribed Roles like Product owner, Scrum Master||No such prescribed roles.|
|Scrum resists change within an iteration||Free to add any task in “To do”|
|Scrum board is reset after each iteration||Not necessarily done as the focus is on to finish one task completely and then remove.|
|Scrum prescribes cross-functional teams||The team can set the ground rules as who can change/own the board, experiment and optimize|
|Scrum backlog items must fit into a sprint||No such rule but Kanban focus on minimizing lead time and level the flow.|
|Scrum prescribes estimation and velocity||No such things are prescribed but suggested a way to break them into similar tasks and estimate them roughly just to give an idea about how much work can be completed per unit of time|
|Allow working on multiple projects simultaneously||Can be distinguished by swim lanes or different color coding|
|Burn down charts are prescribed to know the progress of the sprint||No prescribed charts|
Now the whole workflow is on the same board. In the example above the “Backlog” column is just a general Wishlist, in no particular order. The “Selected” column contains the high priority items, with a Kanban limit of 2.
The “Dev” limit of 3 is shared among the two sub-columns. Why? Let’s say there are 2 items in “Done”:
That means there can only be 1 item in “Ongoing”. That means there will be excess capacity, developers who could start a new item but aren’t allowed to because of the Kanban limit. That gives them a strong incentive to focus their efforts and helping to get stuff into production, to clear the “Done” column and to maximize the flow. This effect is nice and gradual – the more stuff in “Done”, the less stuff is allowed in “Ongoing” – which helps the team focus on the right things.
Scrum is less prescriptive than XP since it doesn’t prescribe any specific engineering practices.
XP (Extreme Programming) is pretty prescriptive compared to Scrum. It includes most of Scrum + a bunch of fairly specific engineering practices such as test-driven development and pair programming.
The five values of XP are communication, simplicity, feedback, courage, and respect.
The principles of Lean thinking are:
Lean says to relentlessly eliminate anything that isn’t adding value and only work on what we absolutely need to be doing at this moment in time. Eliminating waste means eliminating useless meetings, tasks, and documentation.
Lean says to respect that the people doing the work are the ones that best know how to do it. Give them what they need to be effective and then trust them to do it. Software development is about learning, so structure the work to ensure we’re continuously learning. Finally, develop in a way that builds quality into our product, because there’s no way to continuously deliver fast if we have to keep going back to clean up our messes.
More importantly the Agile practitioner should be the “seller of Agile” wherever he goes. His heart and soul should think only about its principles, manifesto and different ways of implementing it.
Again a very important interview question as interviewer wants to know if you faced this situation earlier, if yes how you overcome it.
This is a very important concern in any team and it needs to be solved very diligently.
Because cherry picking can be done by senior people also.
For an interview this will be a trap so don’t tell that I will have to tell him to do this and that…No micromanagement. Don’t try to take the driver seat…
There are 4 different levels of SAFe in 4.0 version onwards.
They are shown in the figure below:
This level is the same as that of what we know about Scrum, it’s Artifacts, roles and events/ceremonies.
All scrum teams are part of one or the other ART (Agile Release train).
ART is explained in the below diagram. Basically, this is a team of 50-100 people (cross-functional) responsible for defining and deploying the new system, plan, commit and delivers the solution to the customer in a particular time frame.
At this level product and program manager has the authority to define the Backlog.
At this level, different roles are DevOps, System Architect, RTE, Product Management, System Team, Business owners, Customer, UX Architect.
The main events of this level are:
Duration is about 8-12 weeks. A very huge event where all the cross-functional team members across the globe participate and work towards the common goal. A valuable increment of the system is developed and delivered.
Highest level of concern/involvement in SAFe is portfolio Level.
Considering 100% capacity for each team member will lead to overtime and Stress in the team environment. So, it is never recommended.
Before the sprint starts, in the sprint planning meeting Scrum Master can prepare one excel sheet containing a column of the name of each team member, any vacations planned, % contribution for the project.
Consider a 2 weeks Sprint, 10 days and 5 people on board, the table may look like this:
|Name of the team member||Available days for the sprint (Vacations Planned may be or others)||% Productivity|
The total number of hours.
Per day if we work 8 hours
Total =190 hours
Going beyond 0.8 can be risky and can derail teams too.
In this sprint, the total available working hours for the team is 190 hours. The reason for asking the productivity for the sprint is that out of 8 hours per day we need to spend on meetings, some presentations, interviews, and Mails etc. Generally, we consider 6 hours a day of each team in which they work to their full capacity. The why 50% or 60%? The reason could be
After arriving the figure called 190 hours the same can be filled into the Project Management tool.
But the question may arise why hours??? Here we are calculating tasks details which are done in a number of hours. i.e. breaking the user story into tasks.
To the question about team member working on multiple projects. Ideally “Not recommended”. But It depends upon the situation. When doing heavy development, it is better to have a single product. If doing lighter enhancements, multiple products can be supported.
The "rule of thumb" to address that is to work on one product until you have something to deliver, and only at *that* point chooses whether the next deliverable thing will be from this product or the other. Working on 2 different features at the same time delays the delivery of both - even when for the same product. If you already know you want them both finished before you deliver, then working in parallel is not too much of a problem; other factors than early ROI and early feedback from having delivered, take precedence. But this rarely applies when working on 2 different products that are very likely to have independent delivery cycles.
|Agile Methodology Interview Questions and Answers||90|
|Agile Scrum Interview Questions and Answers||20|
|Basic Agile Interview Questions||10|
|Agile Concepts Interview Questions||10|
Let’s say the following are our arrays:
[20, 40, 60] [80, 100, 120]
var res = arr1.concat(arr2);
Let us now merge the above two arrays:
The output displays the merged arrays:
Array 1 = 20,40,60 Array 2 = 80,100,120 Merged Arrays = 20,40,60,80,100,120
There is no standard/universal checklist to measure an organization’s successful Agile adoption. So, every organization should develop its own set of criteria based on what matters most to them. Some of the examples include
While doing Agile is about following sets of practices, it is the Agile attitude which complements the practices and helps the organization reap maximum benefit. So, if a team is just following a defined set of practices without understanding the rationale behind it and not having an Agile mindset, the team will not succeed. So, I shall ask a few questions like Has your team adapted any of the Scrum practices to suit your team’s need? How frequently does your team release value to its customers? Does the team hold each other accountable to sprint and project success and are they empowered? Does the team stride to improve their technical expertise and is time buffered for innovation? How does the team respond if there's a crisis or problem that makes a deadline or planned milestone no longer possible to achieve?
These are just a few quick litmus tests to see if a team is being Agile and if a team is negative on any of the above questions, then they are most definitely not there yet.
Metrics in Agile can have three most important goals:
Velocity can be a very useful predictor of how much work an Agile team can compete in the future. In general, the impact can be ignored with the idea that history repeats itself and that team members will probably take time off in the future at the same rate they took time off in the past and reduced productivity balances off over a long term.
However some situations demand adjustment for holidays and team member vacations, like in a situation when a project is of short duration, a team member is on leave for more than a normal period, etc. In such cases, velocity is adjusted proportionately to the full team, with an understanding that everyone can do everything. So, Predicted Velocity = Average Velocity × (Planned Working Days ÷ Average Working Days).
But in case if team members are not interchangeable, velocity is adjusted proportionately based on skills.
Agile planning is iterative in nature.
|Product Vision||To detail what the product is, who will and why use it, and how the product supports the company’s overall strategy||Product Owner||Revised once a year|
|Product Roadmap||To provide a visual overview of the high-level product requirements, timeframes for deliverables, prioritization and estimations details of all releases over time||Product Owner||Revised twice a yea|
|Release Plan||To describe the high-level timeline for product releases||Product Owner||Revised twice/four times a year|
|Sprint Plan||To describe sprint goals and requirements and how those requirements will be completed||Project Team||Revised once a sprint|
|Daily Scrum||To discuss on what was completed yesterday, what will be done today and any roadblocks found||Project Team||Daily for 15 minutes|
|Sprint Review||To demonstrate the working product/deliverable to stakeholders for feedback/acceptance||Project Team||Monthly, or at least for each sprint, for an hour|
|Sprint Retrospective||To discuss on product and process improvements and picking on at least one area to focus on continuous improvement||Project Team||Monthly, or at least for each sprint, for an hour|
The quality of execution in any project largely depends on choosing the correct methodology. In some cases, Agile will be an ideal option, but not always. A flexible development model should be applied in the following cases:
The below matrix also represents where Agile works well.
A Spike is a key tool used by agile teams to investigate and resolve problems as early as possible. It is a short time-boxed exploration of an approach to reduce project risk by learning just enough about the unknown aspect of a user story.
Although spikes can be done at any time during a project, they are generally don’t at the start of a project, before the development effort begins.
There are two types of spikes:
The entire Scrum team owns risk management and is responsible for mitigating it together, they should always think about the risks that could threaten the success of the project.
Accepting only fully groomed story for a sprint, making the increment size smaller, are few effective ways to reduce risks early in the project lifecycle. Daily stand-up (What is blocking progress?), sprint review and retrospective are few platforms to identify and discuss risks.
When a team encounters risks, they should maintain them in a way that ensures that the status and priority of each risk is visible and monitored. Risk burn-down chart is one such effective graphical indicator. Depending on the impact a risk causes, some can be accepted, some just monitored, and priority risks added to the backlog for mitigation planning.
While the traditional triangle of constraint kept Scope as fixed and Time & Cost as a variable, the Agile Triangle of Constraints keeps Cost & Time as fixed and Scope as a variable component.
This reversal of the traditional triangle means that the agile team allows the scope to vary within the fixed parameters of cost and time. In other words, we aim to deliver the most value we can by X date within X budget. As knowledge work projects are characterized by experimentation and uncertainty – and the end product can be refined forever, we need to determine acceptable operating boundaries, which usually takes in the form of cost and time constraints. For example, let’s say we are developing training materials for a course on agile. For a project such as this, we could continue adding and tweaking our lesson material and exercises indefinitely. Instead, we need to get to an acceptable performance point, and then have the discipline to stop.
Process tailoring refers to adapting our implementation of agile to better fit out project environment.
As a general recommendation, teams that are new to agile should use their methodology “out-of-the-box” for a few projects before attempting to change it. That’s because the problems a new team encounters with a standard technique or practice should be due to their lack of skill or experience using that technique, rather than issues with the technique itself. By discarding or changing the practice before its value is recognized, we risk losing the benefit the practice was originally designed to bring to the project.
In addition, the team should go through the three-step process to increase mastery and address the appropriate time and place for agile process tailoring.
Shu: Obeying the rules – means “to keep, protect, or maintain”
Ha: Consciously moving away from the roles – “to detach or break free”
Ri: Unconsciously finding an individual path – “to go beyond transcend”
Fail fast is a philosophy that suggests if a proof-of-concept effort isn’t successful, we can try a different approach and if none of the approaches are successful, we cut the losses.
The principle behind it is that rather than continuing on a project that would have eventually failed, the remaining funds and resources from the project can now be directed to other projects that are awaiting resources.
Fail Fast principle is also applied at the software bug lifecycle. As we know, the longer it takes for a bug to appear on the surface, the longer it takes to fix and the greater it costs.
Fail-fast makes bugs and failures appear sooner, thus:
Fail-fast is the principle behind many agile practices like Test Driven Development and Continuous Integration.
Agile is an empowering process that promotes small, continuous iteration of development and testing throughout the cycle of project development. It is the ability to respond to changes. Agile helps teams to respond quickly to unpredictable feedback that they receive during a project. Regular meetings called Sprint are held by the team to assess the project on a regular basis. The major aim is to analyze and improve the product throughout the development process. Having an Agile way helps companies produce the desired product that is valued in the competitive market. The Agile teams work in a cross-functional manner.
Many well-known companies around the globe use the Agile approach in order to improve their processes. Some of the top industry majors applying the Agile approach are IBM, Cisco, AT&T, Microsoft, etc.
Professionals can opt to become an Agile Coach, Scrum Master, Agile Product Owner, etc. According to Ziprecruiter.com, the average salary for the role of Agile Coach in the United States is $149,541 per year.
The demand for Agile Coach and Scrum Masters has increased exponentially in the past few years. Hence it is very important for the candidates to prepare well for their interviews.
To give you an idea of the types of questions which may be asked in an Agile interview, we have brought you a list of agile interview questions framed by experts, who were also former interviewers.
These are the best samples of agile methodology interview questions which will aid you to crack your Agile interview.
After extensive research, we have curated the common agile interview questions that you might encounter in your upcoming interview. All these agile methodology interview questions and answers for experienced and freshers will help you crack the Agile interview and make you the best among all your competitors.
So, in order to succeed in the interview, you need to read, re-read and practice these agile interview questions as much as possible.Make the most out of it. All the best!