This Festive Season, enjoy 10% discount on all courses Use Coupon NY10 Click to Copy

Agile Interview Questions

Face any Agile interview like an expert with the top-recommended Agile interview questions and answers for experienced and freshers. An Agile interview guide will be a great start, and we have you covered. To be able to explain Agile methodology in an interview, you need to be thorough with the Agile methodology interview questions for developers. Find all relevant details in this comprehensive guide.

  • 1 Course(s)
  • 20 Question(s)
  • 80 Mins of Read
  • 744+ Reader(s)

Beginner

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.

 Graph for burn-down chart

Graph for blue down chart

 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.

Graph for burn up

Agile Estimation techniques:

1) 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 is 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 represent 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 the highest and lowest values explain their opinions and why they chose this value, until a final consensus is reached.
  • A good technique for a 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 than a story with 2 story points.

Planning Poker

2) T-Shirt Sizes:

  • Items are estimated as T-shirt sizes XS (Extra Small), S (Small), M(Medium), L(Large), XL (Extra Large), XXL (Double XL)
  • Perfect technique to give a rough estimate of the large backlog items.
  • Useful and quick estimation needs to be done.
  • The disadvantage is that L to someone may seem XL to someone. After discussion and resolving the mismatched, consensus can be reached to get the final estimate.

T-Shirt Sizes

3) Dot Voting:

  • This is basically a ranking method to decide the order of the Product Backlog from the highest to the lowest priority stories.
  • To start this, post all the user stories along with their descriptions on the wall
  • All the stakeholders are given 4 to 5 dots (mostly color pencil or pens).
  • They are asked to give their votes on the user stories they prefer.
  • The one which receives the highest number of votes is considered the highest priority user story.

Dot Voting

4) Bucket System

  • It is a good technique where a large number of items needs to be estimated with a large number of estimators.
  • Different buckets are created with values same as that Poker cards.
  • These are sequentially arranged on the table.
  • The stories need to be placed on these values where the estimators find it suitable.
  • Before placing the user story, estimators must have a clear understanding of it. Discuss the complete requirements and feature details.
  • At last sanity check is performed by all the participants. If any participant finds a wrong bucket assigned to an item then they can bring it to notice and can be discussed until final consensus is reached.

Bucket System

 5) Large/Uncertain/Small

  • This is a rough version and is the simplification of Bucket system where there are only 3 sizes. Large, Small, Uncertain.
  • The estimators are asked to place the items in one of the categories. First, the simpler ones are chosen and placed in the Large and Small category after that complex are chosen and placed.
  • A good technique when there are comparable items in the backlog.

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:

 Large/Uncertain/Small

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? 

Fibonacci number

There are 4 ceremonies in Scrum process.

  1. Sprint Planning Meeting
  2. Daily Scrum
  3. Sprint Review Meeting
  4. Sprint Retrospective Meeting

Scrum ceremonic

 

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

Why is Backlog grooming meeting is important?
  1. Increases efficiency of the team by greatly reducing uncertainty and unknowns.
  2. Better refined stories are more accurately estimated, more accurately tested, and more accurately implemented
  3. Increases efficiency of the team due to the benefit of shared knowledge gained by the entire Scrum team being in the refining.
  4. Allows the team to maintain a sustainable, higher pace.
  5. When done well, refining greatly reduces the time required for a Sprint Planning meeting.

1) Sprint Planning Meeting: 

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.

2) Daily Scrum: 

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.

3) Sprint Review:

Attendees: Development team, Scrum Master, Product Owner

Optional-Project Stakeholders

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.

4) Sprint Retrospective 

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.)

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

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:

  1. Customer urgently wants this feature to be done in this sprint.
  2. The new requirement is small enough to be implemented.
  3. Sometimes due to some technical issues, he wants the team to stop working on that and start with new (Even though they have invested time on that). Example: No more support for the previous versions, hardware outdated etc. 
  4. Some legal issues which need to be addressed.

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:

  1. The product owner can cancel the current sprint and start the new sprint, sprint planning again with the prioritized backlog.
  2. Add it to the current sprint, do the estimate. Suppose new User story has 15 hours of work, and if we have some User Story not started or have 15 hours of work remaining then that can be removed from the sprint. So that the balance can be maintained and velocity remains constant.

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.

  • Test conditions written where beneficial to a story
  • Unit tests written (where crucial) and passing
  • Acceptance tests written,executed,and passing.
  • Functional testing complete
  • System Testing &Blog Fixing, for functionality implemented.
  • Test cases written and passing with expected results,where the work requires it
  • Regression Tested where appropriate.
  • Developer documentation in Wiki(barely sufficient)
  • Code complete
  • Code committed
  • Code pushed
  • Code merged to default branch
  • Code reviewed
  • Meets acceptance criteria

By asking this question interviewer wants to check your knowledge on Agile testing.

Agile Testing

Traditional 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.

Behavior-Driven Development (BDD)

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.

Advanced

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.all types of Projects

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.

Forming-
 Most team members are new, polite and humble at this stage also the roles and responsibilities are not clear to the team.

Storming-
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.

Norming-
 This is when people start to resolve their differences, appreciate colleagues' strengths, and respect your authority as a leader.

Performing-
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:

  1. Analyze the reason for conflict.
  2. Talk to the team members individually and try to understand them from their perspective.
  3. You should make them understand the common goals of the team and work towards it, as Scrum always believe in collaboration over tools and processes.
  4. Guide them to take criticism as a step towards your success goals.
  5. Do more frequent team outings and team building events.
  6. After each sprint completion appreciates the efforts put in by each team member and celebrate this by organizing small snacks or lunch get together after retrospection.

 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 – TestableI – 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.

  1. First, check that the project is suitable for applying Scrum or not. Check Question 1 for more details.
  2. If the project looks suitable for Scrum, then get the details of the Project like (Skillset required, requirements, technical details etc.).
  3. Get the details of the team members to example their skill set, prior knowledge of Scrum etc.
  4. If the entire team is new to this process, then it is very important to send them for the basic Scrum training. (If you are capable of doing so, tell the management about it.)
  5. Have a good balance of Developers, Testers, Architect, DevOps Engineers with good technical skills required for the project. (Doesn’t mean the best technical knowledge in one team).
  6. Have one on one and various group meetings to clarify their doubts and explain their responsibilities. Discuss the Agile Manifesto and 12 principles and encourage them to be self-organized and work with collaboration.
  7. Co-locate the development team removes any partitions, bookcases, furniture if any.
  8. Get some whiteboards permanently for your team, select the place for daily stand up.

Make sure the board is right in front of a team where the daily meeting is held.

  1. Select any Project Management tool which fulfills all your requirements (Jira, Rally etc.)
  2. Co-locating the Development Team, will help empower them to self-organize, makes it easier for the team to learn from each other (cross-functional), and fosters direct, face-to-face communications.
  3. Explain to the team about the “Definition of Done” which is a very critical part, as we do not want to compromise on the quality of the product.
  4. Set up the DevOps environment and get the continuous build integration, automation right from the start of the project.

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:

  1. Split the user Story.

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. 

  1. Product Owner may also say that unless all the tasks of a user story are completed we cannot accept. In this entire, a user story is transferred to the next sprint and re-estimated. (Not completed tasks.)

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:

  1. When we want to implement an agile approach consistently across larger, multi-team program and portfolios.
  2. Project having 5-10 Scrum teams distributed across various geographical locations.
  3. When a team wants to work independently.
  4. When an organization wants to improve its product development lead time.
  5. When you want to implement Agile across an organization and you are not sure of various roles and responsibilities and how they align and coordinate with each other.
  6. When multiple teams are running Agile, but regularly facing delays, no collaboration, and failures.
  7. Decentralized decision making.

The benefits of SAFe are:Benefits of SAFe

Its principles are shown in the diagram below:Foundation of scaled agile framework

 Another agile methodology is Kanban, XP (Extreme Engineering, Lean thinking).

Let us compare the Kanban and Scrum Approach.

Scrum

Kanban

More perspective

Less

Limit your (WIP) PER ITERATION

Limit your WIP (PER WORKFLOW)

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

Similarities 

  •  Both are Lean and Agile 
  •  Both use pull scheduling 
  •  Both limit WIP 
  •  Both use transparency to drive process improvement 
  •  Both focus on delivering releasable software early and often
  •  Both are based on self-organizing teams 
  •  Both require breaking the work into pieces 
  •  In both, the release plan is continuously optimized based on empirical data (velocity/lead time)

Scrum Board:

scrum board

Kanban Board: Kanban board

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.

  1. Extreme Programming empowers your developers to confidently respond to changing customer requirements, even late in the life cycle.
  2. Extreme Programmers constantly communicate with their customers and fellow programmers. They keep their design simple and clean. 
  3. They get feedback by testing their software starting on day one. They deliver the system to the customers as early as possible and implement changes as suggested. 
  4. Every small success deepens their respect for the unique contributions of each and every team member. 
  5. With this foundation, Extreme Programmers are able to courageously respond to changing requirements and technology.

Lean Thinking:

The principles of Lean thinking are:

principles of Lean Thinking

Lean Thinking

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.

  1. Engage people in this discussion by various means. Not necessarily in meetings can be in during Lunch time, coffee time etc.
  2. Arrange for different types of workshops to train them.
  3. Call them for the sprint planning, review, and retrospection.
  4. Discuss the velocity, lead time change from idea to product launch and level of customer satisfaction during this process.
  5. Arrange for small pilot projects for their domain to give them more insights into this process.
  6. Product and engineering teams can demonstrate that scrum mitigates risk (i.e. the prediction of when new features could be made available), thus contributing to other departments’ successes in planning and execution.

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.

  1. As an Agile Practitioner/Scrum Master/Product owner make sure in sprint planning meeting you have clear, refined and prioritized backlog ready for the team to work.
  2. As Scrum given the freedom to any individual to pick up any task…but hold on only on the prioritized stories which are selected by your product owner.
  3. Not doing that will lead to a lot of unfinished tasks at the end and your product may not be in a condition to give a demo to the stakeholders.
  4. If the team fails in understanding the goal of the sprint, the scrum master should help him on this. Additional training might also help.
  5. Let the cherry-picking task be transparent to everyone in the daily scrum (As we use scrum board) and when everyone will see that work in progress are many and not moving towards completed state then you can directly ask the team what the reason could be and what are the possible ways to overcome them. Best way to show your Scrum Master skills.
  6. Some people may do cherry picking if they find something interesting task to be picked up or easy task, but SCRUM is all about team goals, not an individual. An individual may automatically succeed if the team succeeds.

    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:

Different levels

  • Team Level- 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.

Team Level

  • Program Level:

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:

  • ART- This level value of SAFe is delivered by ART. Iteration is for the Team and train is for the program. It delivers a value stream to the organization.
  • SAFe artifact hierarchy is Epics->features->user stories. User Stories then drill down to the team level.
  • Various team (from marketing, development, quality, operations, and deployment) forms 'Release Management Team'. They will approve routine releases of quality solutions to customers
  • PI planning- 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.

PI deliverables:

PI deliverables

  • System Demos-At the end of each PI (Every 2 weeks) the full integrated work of all teams is demoed. This is in addition to each team iteration demo. Stakeholders provide the feedback and corrective action needs to be taken if required.
  • Inspect and Adapt- This is also held at the end of each PI to demonstrate the solution, get the feedback, solve the problem and identify improvement areas
  • Architectural Runway- It is an existing code base, components, technical infrastructure on top where new features are developed without much change in code.
  • Release Any Time- This separates the development cadence from the solution release cycle. Trains may release whatever is needed at any time.
  • Value Stream Level-This level is optional but required in below cases.
  • The organization is big in size
  1. Complex solutions
  2. The solution requires multiple ART’s
  3. System challenges

  • Portfolio Level-Highest level of concern/involvement in SAFe is portfolio Level.
  1. It provides basic budgeting and other governance mechanisms.
  2. This way it assures that investment in the value streams provides the basic returns for the enterprise.
  3. Portfolio Program Management are key stakeholders and they are responsible for delivering the business results.
  4. Here the backlog contains the EPICS (Which contains many features.), EPIC owners are responsible for driving this.
  5. The main roles involved are Enterprise Architect, PPM (Program Portfolio Management), Epic owners.
  6. Events are Strategic business planning and Epic planning.

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 


A

10days

75

80*.75=60 hours

B

5 days

75

40*.75=30 hours

C

10days

60

80*.6=48 hours

D

2 days

75

16*.75=12 hours

E

10 days

50

80*.5=40 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 

  1. A team member might have to work on 2 projects. (Sometimes other team needs the help of this person)
  2. A team member has to spend time on technical debt for some other project also.
  3. A team member is in training for a few days.
  4. A team member is allocated to support maintenance activities also.
  5. Ceremonies
  6. Unplanned work

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.

Keywords

Keyword
Search volume

Agile Methodology Interview Questions and Answers

90

Agile Scrum Interview Questions and Answers

20

Basic Agile Interview Questions

10

Agile Concepts Interview Questions

10