Q: Tell me about yourself?
First of all, thank you very much for this opportunity, my name is <Name>
As a scrum master
¨ I was responsible for delivering high-quality software, on-time and within budget by motivating and guiding the scrum team with agile/lean principles and practices to achieve the same.
¨ Co-ordinate with PO for sprint backlog management, concept grooming and continuous delivery of features.
¨ Co-ordinate with architects and scrum team for backlog management, prototypes and technical grooming.
¨ Effectively guide and facilitate the sprint ceremonies to consistently achieve the sprint goals (Sprint planning, reviews, retrospective, demo, daily stand-ups, and stakeholder meetings).
¨ Protect scrum team from outside distractions, impediments or team conflicts, and maintain focus on product backlog and project timeline.
¨ Work/collaborate/communicate effectively with internal and external stakeholders
¨ Regularly monitor and control the metrics to meet project/product goals. (E.g. sprint/ release burn down, velocity, defects, etc.)
¨ Build trust & connect, create positive environment by empowerment, facilitating discussions, decision making and conflict resolution with emphasis on problem solving.
¨ Identify and control project risks by means of prevention, mitigation and contingencies.
¨ Ensure that sprint deliverables are adhering to the Quality
Q: Why should we hire you?
I believe you should hire me because I have the past experience and abilities to deliver consistent results to you.
As a scrum master I will help the team reach the agreement on all tasks, project and deadlines, conduct productive and progressive daily scrums and also keep everyone focused on what we have agreed during the meetings.
I will also ensure that I will effectively remove any obstacles and barriers the team will face along the way. I am someone who acts with integrity and honesty and I will work extremely hard to deliver the result am responsible and accountable as scrum master.
Q: Why XXX company?
I believe it’s very important to choose your employer wisely. To be an effective manager, you need to have s supportive management, ambitious vision to work and a focused team.
Before applying, I carried out a research into the organization to make sure that its somewhere I want to work long term.
So, to conclude, I feel that XXX is where I get opportunities to grow, develop and advance professionally in long term.
Q: Where do you see yourself in next 5 years?
In five years from now, I will hopefully still be working for your company either in this role or perhaps gained advancement to higher role.
In five years, I will have developed into a trusted, loyal & committed member of the company who can be relied upon to a great job for you.
I will be able to extend my expertise and help to other departments using my skills and knowledge gained from my role
Q: Strength and Weakness
· Influencing and facilitating skills
· Ability to work as a part of a team.
· Positive in nature.
· Calm under pressure
· Good communicator
· Strong interpersonal and relationship building skills
I sometimes find it difficult to have a healthy work/life balance. I have literally been working hours a day during some difficult and complex projects since I become a scrum master
As years go by, I am becoming a smarter and intelligent scrum master being passionate and fully committed to the role.
Q: What is Agile Project Management?
Agile project management is an iterative and incremental approach to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their end user/client.
Q: When to use Agile?
· Complex projects
· Unclear requirements
· Quick launch of the product
· Minimal Cost of change
· Emphasis on teamwork, transparency & continuous improvement
· No limit on time & budget
· Frequent changes of requirements
· No need to deliver fully functional product at once.
Difference between agile and waterfall methodologies?
· Incremental and iterative approach
· Focuses on customer satisfaction
· Project is split into sprints
· Requirements are expected to change and evolve
· Incorporates changes even late in the development
· Teams are encouraged to be self-organizing
· Focused on delivering working software
Frameworks within the agile
The four values of Agile
Disadvantages of Agile Methodology
· Teams get easily sidetracked due to lack of processes
· Long-term projects suffer from incremental delivery
· The level of collaboration can be difficult to maintain
Agile planning helps you manage and stay on top of any changes that come your way in a project while keeping it firmly grounded.
· Decide what needs to be done
· Estimate the efforts required to get the job done
· Know the best pace for your team
Q: What is Scrum?
Scrum is an iterative incremental approach to software development under agile project management and is the most popular framework under the agile methodology. In Scrum, you split your work into chunks on which you work for set periods of time.
Q: 12 Scrum principles
1. Empirical Process Control – This principle emphasizes the core philosophy of Scrum based on the three main ideas of transparency, inspection, and adaptation.
2. Self-organization – This principle focuses on today’s workers, who deliver significantly greater value when self-organized and this results in better team buy-in and shared ownership; and an innovative and creative environment which is more conducive for growth. More
3. Collaboration – This principle focuses on the three core dimensions related to collaborative work: awareness, articulation, and appropriation. It also advocates project management as a shared value-creation process with teams working and interacting together to deliver the greatest value. More
4. Value Based Prioritization – This principle highlights the focus of Scrum to deliver maximum business value, from beginning early in the project and continuing throughout. More
5. Time-boxing – This principle describes how time is considered a limiting constraint in Scrum, and used to help effectively manage project planning and execution. Time-boxed elements in Scrum include Sprints, Daily Standup Meetings, Sprint Planning Meetings, and Sprint Review Meetings. More
6. Iterative Development – This principle defines iterative development and emphasizes how to better manage changes and build products that satisfy customer needs. It also delineates the Product Owner’s and organization’s responsibilities related to iterative development. More
Q: Scrum Values
Scrum team members have the courage to do the right thing and work on tough problems.
Everyone focuses on the work of the Sprint and the goals of the Scrum Team.
People personally commit to achieving the goals of the Scrum Team.
Scrum Team members respect each other to be capable, independent people.
The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work.
· Demonstrate courage by taking on difficult tasks.
· Show focus by keeping to your schedule.
· Embody commitment by doing your work well and assuming your team is also.
· Respect your team members by trusting them to do their work independently.
· Model openness by admitting your mistakes and communicating both honestly and kindly about areas for improvement on the team.
Q: Scrum/Sprint lifecycle
· The Scrum cycle begins with a Stakeholder Meeting, during which the Project Vision is created.
· The Product Owner then develops a Prioritized Product Backlog which contains a prioritized list of business and project requirements written in the form of User Stories.
· Each Sprint begins with a Sprint Planning Meeting during which high priority User Stories are considered for inclusion in the Sprint.
· During the Sprint, short, highly focused Daily Standup Meetings are conducted where team members discuss daily progress.
· Toward the end of the Sprint, a Sprint Review Meeting is held during which the Product Owner and relevant stakeholders are provided a demonstration of the Deliverables.
· The Sprint cycle ends with a Retrospect Sprint Meeting where the team discusses ways to improve processes and performance as they move forward into the subsequent Sprint.
Q: Scrum boards
A Scrum board is the face of your process, a visual status of your sprint, showing your work split across different stages of your workflow. A basic Scrum Board has 3 columns, “To do”, “Doing”, and “Done”. . Its one way of ensuring transparency.
Q: Scrum ceremonies
These are the five key scrum ceremonies:
- Backlog grooming (product backlog refinement)
- Sprint planning.
- Daily standups.
- Sprint review.
- Sprint retrospective.
Q: Sprint Zero
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.
Q: Product Backlog Refinement or Grooming
· Done before the next sprint starts. the product owner and some, or all, of the rest of the team review items on the backlog to ensure the backlog contains the appropriate items, that they are prioritized, and that the items at the top of the backlog are ready for delivery.
Q: Sprint Planning Meeting
· What can be delivered in this sprint iteration?
· How to achieve that?
· Time-boxing the activity
· Making the team stay focused on the intention of the meeting
· Facilitating and Resolving (if required) any deadlocks in the discussion
· Can help them to commit the right amount of work, as per their available capacity.
· To make sure that the team is invested and asking the right questions.
· Result: A Sprint Goal
Q: Daily Standups
Daily Standups are short meetings held every day to discuss work and different challenges the team is facing. These meetings are done standing around the Scrum Board, so it’s a good idea to have the board in an open space.
Q: Sprint Demo & Review
A sprint review is held at the end of every sprint to inspect the product increment and update the product backlog if needed.
Q: Sprint Retrospectives
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.
- What shall we continue?
- What needs to be stopped?
- What needs to be started?
Q: Scrum Artifacts
Q: Product backlog
The product backlog is a list of new features, enhancements, bug fixes, tasks, or work requirements needed to build a product.
Q: Sprint backlog
The sprint backlog is a set of product backlog tasks that have been promoted to be developed during the next product increment. Sprint backlogs are created by the development teams to plan deliverables for future increments and detail the work required to create the increment.
The sprint is a timebox of one month or less during which the team produces a potentially shippable product increment.
Q: Product increment
A product increment is the customer deliverables that were produced by completing product backlog tasks during a sprint. It also includes the increments of all previous sprints.
Q: Scrum Metrics
· Sprint Goal Success: Cumulative flow diagram
· Escaped Defects and Defect Density
· Team Velocity: Velocity Chart
· Sprint Burndown: Burndown Chart( work remaining)
· Time to Market
· Return on Investment
· Capital Redeployment
· Customer Satisfaction
Monitoring the Scrum Team
· Daily Scrum and Sprint Retrospective
· Team Satisfaction
· Team Member Turnover (replacement of team members)
· For team meeting, go with the burndown chart and have a discussion based on it.
· For Scrum of scrum or higher management meeting, burn up chart will be more suitable. Till this time, we could achieve this much amount of user stories & business values. Show what’s the trend going on
So basically, based on the stakeholder we have to choose the metrics.
Defect Density; Defect density is the number of defects found in the software product per size of the code.
Defect Density = Defect count/size of the release
Q: Definition of Ready
Definition of Ready defines the criteria that a specific user story has to meet before being considered for estimation or inclusion into a sprint.
- The story should be written exactly in the ‘user story’ format.
- Acceptance criteria must be understood by the team.
- A Team needs to estimate the story.
- The team should understand how to provide a demo of the features.
- Performance criteria should be understood by the team.
Definition of Ready for a user story:
- Well-defined User story
- User story acceptance criteria defined
- User story sized by the delivery team
- Scrum team accepts user experience artifacts
- Performance criteria identified
- The Person who will accept the user story is identified
- A Team is able to ‘demo’ the user story.
Definition of Ready for a sprint:
- Prioritized sprint backlog
- Defects, user stories and other work the team has committed to are contained in the sprint backlog
- No hidden work
- All team members have calculated their individual capacity for the sprint
Q: Definition of done
Each team has its own definition of “done” and acceptance criteria to determine when a user story gets completed. The Definition of Done is an agreed-upon set of items that must be completed before a project or user story can be considered complete.
A DOD is something like
· Security Testing Done
Q: Burndown charts and Burn Up charts
A burndown chart plots the estimation points you “burn” in your sprint across time. It is one of the key indicators for measuring progress in Scrum. Also shows how much work is remaining in the sprint in terms of task hours graphically.
In the Burn-Down chart, the vertical axis shows the amount of work and the horizontal axis shows the amount of time passed from the beginning of the project or the number of Sprints passed.
Burn up charts indicates the amount of work completed in the sprint. 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.
Q: What are stories, epics, initiatives, and themes?
- Stories, also called “user stories,” are short requirements or requests written from the perspective of an end user.
- Epics are large bodies of work that can be broken down into a number of smaller tasks (called stories).
- Initiatives are collections of epics that drive toward a common goal.
- Themes are large focus areas that span the organization.
Q: Sprint velocity
Velocity is a measure of the amount of work a Team can tackle during a single Sprint and is the key metric in Scrum. Velocity is calculated at the end of the Sprint by summing up the Points for all fully completed User Stories. Points from partially-completed or incomplete stories should not be counted in calculating velocity.
Q: Impediments in Sprint
· Basic example, sometimes the team misses about an access of a portal or a tool where the task is to be developed and tested.
· Gaining the access to the portal takes enough time and sometimes spill over happens.
· Unplanned leaves, there will not be enough update on the story board and team member who can pick the user story and complete it doesn’t know ehere to start with
· So, we use the retro platform and identify some action items and work as team
· Inspect and adapt
Q: Entry and Exit Criteria
· We should have a refined, prioritized backlog.
· The capacity of the team
· The velocity of the team
· Sprint backlog and DOR achieved
· No Specific exit criteria as it a time boxed event.
· If some or any of the item are not finished you can’t extend the sprint.
· If it’s a 2-week sprint, then it will end on the 10th day even if its half or full incomplete stories
· As a best practice task should ne completed in a days’ time.
· Stories is available in the sprint backlog and is voluntarily assigned to a team member.
· Goal related to the task is achieved
· New->Assigned->In progress->Done
· When we pick a user story for execution, the fearture is automactically entered
· Child items, user stories gets closed
· If there is some bug, have to check the priority of the bug and then close.
Q: Story points
Story points are units of measure for expressing an estimate of the overall effort required to fully implement a product backlog item or any other piece of work.
Story point Calculation
Story Points = Development Effort + Testing effort + Resolving dependencies +other factors
Story Points vs Hours
Man-hours are easy to understand, there are a few big drawbacks to this technique:
· Some tasks are difficult to estimate precisely
· If one developer estimates a project but another completes the task, the estimate becomes invalid. The time needed to complete a task will vary based on a developer’s level of experience
· People generally underestimate obstacles they might face and consider only the best-case scenario
A Story Point is a metric used in Agile to estimate the difficulty of implementing a particular User Story. Story points are typically a unit of measuring three things, that each work item consists of:
· The amount of work to do
· The complexity of the work
· Any risk or uncertainty in doing the work
Benefits of Story point
¨ No correlation with skills and experience of the estimator.
o A specialist who estimates a task isn’t always the one who implements it. Senior and Junior developers need different amounts of time to complete the same task. The only way to avoid all this is to make a developer who estimates a project also implements that project. The estimate doesn’t depend on who’s implementing the story. All team members, with different skill levels, can discuss it together and come to a single conclusion.
¨ Velocity is Tracked
o Team members discuss ways to achieve greater velocity during retrospectives after each sprint. The higher the team’s velocity, the higher the team’s capacity to perform a given task quicker and more efficiently.
¨ No Re-Estimation if Velocity Changes (Flexibility)
o Velocity of a person with respect to another person
o Velocity of the team increased
¨ Perfect for high-level estimation
Imagine that the total work scope is 200 Story Points, and you estimate that User Story with 5 Story Points, assuming that you’ve considered all the risks and difficulties. However, after you gain access to the documentation, you find out that the task is more complicated, so you need to re-estimate the User Story to 8 Story Points.
Now it’s easy to recalculate the release date if needed.
Good user stories
Q: Story Points Estimation Techniques
1. Planning Poker
Planning poker is an agile estimation technique that makes use of story points to estimate the difficulty of the task at hand. Based on the Fibonacci sequence, the story point values that can be assigned are 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100. Each of these represent a different level of complexity for the overall project. a Fibonacci sequence gets father apart as the number gets bigger making the estimation more relative.
2. T-Shirt Sizes
If you think about T-shirts, there are multiple sizes to choose from. More specifically – there is extra-small (XS), small (S), medium (M), large (L) and extra-large (XL). This technique uses these sizes as story points for the size of the project, and it is a useful way of thinking when estimation needs to occur.
3. Dot Voting
4. The Bucket System
5. Affinity Mapping
Q: Story board
A story board is a visual representation of the progress of software project which generally has 4 columns; To do, In progress, Test & Done
Q: Challenges in User stories
¨ Sometimes the user story is not sliced properly in view of the functionality.
¨ The team member won’t be able to estimate properly and estimation goes much higher.
¨ It can span across the sprint.
¨ No time to incorporate the changes and Spill over happens and misses the sprint goal.
¨ So, we try to slice it small enough so that it satisfies the INVEST principle.
¨ Sometimes the use stories won’t be clear enough to estimate and the scope varies and DOD doesn’t get met.
¨ In the end the acceptor and developer have some disagreements.
Q: Challenging Scrum Ceremony
¨ Retrospective: Its very challenging to make the team talk.
¨ Most of them comes unprepared
¨ So we have to motivate and mentor them to do more in the scrum ceremonies
Q: Working agreement
Work agreements are the set of rules/disciplines/processes the team agrees to follow without fail to make themselves more efficient and become self managing aspect of scrum. These agreements help the team build a shared understanding of what it means to work as a team.
Q: Empirical Process Control?
An empirical process is implemented where progress is based on observation and experimentation instead of detailed, upfront planning and defined processes.
· Learn as we progress
· Expect and embrace change
· Inspect and adapt using short development cycles
· Estimates are indicative only and may not be accurate
Q: Empirical Process Control in Scrum
· Transparency ensures that aspects of the process that affect the outcome must be visible to those managing the outcomes.
· The various aspects of the process must be inspected frequently enough so that unacceptable variances in the process can be detected.
· The adjustment must be made as quickly as possible to minimize further deviation.
Increase ROI for projects with Scrum
Q: Scrum Phases and Processes
1. Create Project Vision
2. Identify Scrum Master and Stakeholder(s)
3. Form Scrum Team
4. Develop Epic(s)
5. Create Prioritized Product Backlog
6. Conduct Release Planning
Plan and Estimate
7. Create User Stories
8. Approve, Estimate, and Commit User Stories.
9. Create Tasks
10. Estimate Tasks
11. Create Sprint Backlog
12. Create Deliverables
13. Conduct Daily Standup
14. Groom Prioritized Product Backlog
Review and Retrospect
15. Convene Scrum of Scrums
16. Demonstrate and Validate Sprint
17. Retrospect Sprint
18. Ship Deliverables
19. Retrospect Project
Q: Achievement at the end of the Sprint
¨ How my team worked on the success of the action items
¨ How well the team is organized
¨ How they evolved w.r.t to previous retro
¨ Team work and coordination improvement
Health of the team
¨ Burndown charts
¨ Start Stopping and stop starting
¨ Pick up one user story, complete it and pick next
¨ So that there won’t be many incomplete stories
¨ The iteration value will be good at the end of the sprint
¨ We will be defining the action item that has to be don’t in a sprint.
¨ Any addition or deletion to this during sprint execution causes a scope creep.
¨ It calculated at the end of the sprint
¨ PO is uncertain of the priority at the beginning.
¨ Requirement is coming from the management.
¨ Started the work without analyzing the risk or dependencies.
Added/Removed Scope points/Committed story points = % of scope creep.
¨ Be proactive. Determine and agree upon a change management process upfront.
¨ Prioritize. Look at what can be descoped to accommodate new requests.
¨ Be transparent. As soon as scope creep appears, bring it up with clients and stakeholders.
¨ Analyze impacts. Work out the impacts (both positive and negative) of changes, and present solutions to your client or stakeholder in order to move forward.
¨ Embrace it. Work out what’s necessary for a testable, usable product—if that means changing scope, look at ways to incorporate the changes.
Q: DEEP – Good Product Backlog
DEEP identifies four key attributes of a high-functioning product backlog.
¨ Detailed appropriately: Items in the backlog should contain enough contextual information for you cross-functional team to understand and discuss.
¨ Estimated: The effort involved with each user story should roughly estimate with a standardized measure agreed upon by the team.
¨ Emergent: Because a product backlog evolves, it’s easy to add new stories and items—or remove them—as new information arises. Nothing is permanent.
¨ Prioritized: Items on the backlog are ranked based on their value and the strategic purpose(s) they serve, with higher-value items placed at the top.
· To Spike a story is about writing a POC(Proof of Concept), developing a prototype or conducting some research so that the story can overcome its technical, functional or other issues.
§ Team uses spikes to arrive at a decision or solutions When PO comes with a high priority story which needs to be delivered in the sprint but doesn’t have much details around it and wrong estimation lead to incorrect velocity of the team
§ Requirements need lot of research for large sized complex technical user stories to check technical and functional usability.
§ The team working on a solution but unsure that it will work
§ The team is having more than one solution and not sure which is the best.
· Benefits of Spikes
§ Minimize the uncertainty of the risk and uncertainty of the project/Product
§ Break down the epics into smaller stories
§ Provide the right solution to the requirement or problem
§ Make decision much easier
§ Provide collective decision and responsibility
· Technical Spikes
§ Determine the buy or build option
§ Determine the load impact of a function
§ Evaluating a new technology
§ Determine the current usage pattern
§ Determine the potential performance of a current user story
· Functional Spikes
§ Make the user story simple and break down the complex parts
§ Determine the risk factors and uncertainty.
§ Evaluate the prototypes, Proof of concepts (POC) and wireframes
§ Evaluate the user interface mockups
§ Evaluate the page flows
· Proof of Concept (POC)
§ Applicable (How relevant it is)
§ Practical (resources)
Steps in POC
¨ Prove the need.
¨ Problem – Solution mapping
¨ Create MVP
¨ Learnings and roadmaps
Q: Risk Management in Scrum
Risk Categories can be regarding technology, Requirement, Human Resource, Budget, Quality, Knowledge, Time/Schedule, Technical debts or external factors.
Risk Management: Identification, Assessment, Responses and Review
§ Develop in priority Order (Product Backlog)
§ Clear goal and scope of the iteration (Sprint planning)
§ Small estimates that are tracked daily (Sprint backlog)
§ No changes within the iterations
§ Active daily management and Bidirectional report (Daily Scrum)
§ Team forced to face the issues earlier
§ Delivery of the working software every iteration (MVP)(Sprint execution)
§ Consumer see product constantly (Sprint review)
§ Review and adjust every iteration (Sprint Retro)
Q: RAID Analysis – Risks, Assumptions, Issues, and Dependencies
During Sprint or Release Planning it is useful to capture any Risks, Assumptions, Issues, and Dependencies that we identify during the planning, that might impact the successful execution of the plan. A RAID diagram is useful for this.
RISK: If the likelihood of the event happening and impact to the project are both high, you identify the event as a risk.
Assumptions : Any factors that you are assuming to be in the place that will contribute to the successful result of your project. The log includes details of the assumption, the reason it is assumed, and the action needed to confirm whether the assumption is valid.
Issues : Something that is going wrong on your project and needs managing. Failure to manage issues may result in a poor delivery or even complete failure. The log includes descriptions of each issue, its impact, its seriousness and actions needed to contain and remove it.
Dependencies: Any event or work that are either dependent on the result of your project, or on which your project will be dependent. The log captures whom you are dependent on, what they should deliver and when. It may also include who is dependent on you.
RAID management helps you:
· Deal with potential problems before they happen
· Understand when you need to escalate for more senior assistance
· Ensure everyone understands what you’re dependent on, and that’s dependent on you
· Inform all stakeholders of the planning and delivery dependencies, and assumptions you’ve made for the project
Executing RAID Analysis Sprint/Release Planning
· Prepare the RAID canvas with the following four areas: Risks, Assumptions, Issues and Dependencies
· Ask the participants to write down their notes on an individual post-it for each of the four areas.
· Consider using cards of a different color to represent each type (R, A, I, or D), respectively.
· A note might belong to more than one quadrant. In such cases, write more than one note; each note specifically to the quadrant.
· Conversation and action items about the notes
Few key items to be considered during this exercise
· Resource availability & continuity
· Environmental Risks, Technical Risk
· Quality considerations
· Regulatory, Governance
· Logistics risk
· Outbound dependencies, where your project is dependent on something happening in another team before you can complete a task/deliverable
· Inbound dependencies where other teams are dependent on you delivering before they can complete a task or deliverable
Q: Capacity Planning
Capacity Planning helps the team to estimate the available bandwidth for the team to commit and complete User stories.
§ Story Points: Average velocity of the last 6 or 8 sprints
§ Hours based
¨ Calculate sprint duration
¨ Calculate team availability\Identify Allocation (100% or 50%)
¨ Calculate the hours/days
¨ Default distribution
§ Team holidays
§ Individual leaves
§ Override default working hours
¨ Time for other activities like daily scrum, grooming, planning, reviews, retros..
¨ Focus factor, keep aside a percentage for unseen activities, mails, call or exploration. 90% is ideal
¨ Final Capacity
Q: Stakeholder Management
· Identify Stakeholders
To recognize the decision-makers, you ask the following questions:
¨ Who will furnish funds for the project?
¨ Who will supply resources for the seamless execution of the project?
¨ Who are the end customers for the outcome of the project?
¨ Who will offer other types of support?
¨ Who will be giving guidelines/regulations that need to be followed while working on the project?
¨ Who will provide specifications for the project?
· Analyze Stakeholders
· Stakeholder analysis involves preparing a list of all the potential stakeholders who will be associated with the project in some way or the other.
· Prioritize Stakeholders
· A power-interest grid is used for categorizing stakeholders and prioritizing them based on significance and impact. Provides a framework for managing stakeholders based on interest and influence
· Engage Stakeholders
· Communicate often
¨ we need to define how we’ll be interacting with them
¨ One-on-one conversations – Standing meetings – Scrum ceremonies – program events – Workshops
¨ Define the objectives
¨ Set the frequency
Q: Test Driven Development (TDD) vs Behavior Driven Development (BDD)
TDD is Test Driven Development. This means writing a test that fails because the specified functionality doesn’t exist, then writing the simplest code that can make the test pass, then refactoring to remove duplication, etc. You repeat this Red-Green-Refactor loop over and over until you have a complete feature.
BDD is Behavior Driven Development. This means creating an executable specification that fails because the feature doesn’t exist, then writing the simplest code that can make the spec pass. You repeat this until a release candidate is ready to ship.
Those seem pretty similar, right? They are. The key difference is the scope. TDD is a development practice while BDD is a team methodology. In TDD, the developers write the tests while in BDD the automated specifications are created by users or testers (with developers wiring them to the code under test.) For small, co-located, developer-centric teams, TDD and BDD are effectively the same
Acceptance test–driven development (ATDD)
(ATDD) involves team members with different perspectives (customer, development, testing) collaborating to write acceptance tests in advance of implementing the corresponding functionality.
Nonfunctional Requirements (NFRs) define system attributes such as security, reliability, performance, maintainability, scalability, and usability.
Failing to meet any one of them can result in systems that fail to satisfy THE END USERS
· All source code must be run through a static security testing tool to be analyzed for security flaws, with all issues remediated (security).
· Every web and mobile web pages related to brokerage trading transactions (stocks, bonds, mutual funds) must load in under 2 seconds (performance).
· If a customer has logged into our site and the session is idle for more than 10 minutes, automatically terminate the users session and log them off the system (security).
· All customer facing web pages will use the corporate style guide colors, fonts and corporate approved logos (branding).
· All web pages must support our visually impaired customers through our department Accessibility guidelines and best practices (UX Accessibility).
the most common solution is to describe the NFR in the definition of “Done”.
Q: Definition of Done vs Acceptance Criteria
Definition of Done (DoD) is a list of requirements that a user story must adhere to for the team to call it complete. While the Acceptance Criteria of a User Story consist of set of Test Scenarios that are to be met to confirm that the software is working as expected.
The Acceptance Criteria is what the customer needs. The Definition of Done is what the organization needs.
Q: Agile Estimation Techniques
Agile estimation is about evaluating the effort required to complete each work item listed in the prioritized backlog.
· Making teams accountable for deliverables
· Inducing discipline across the Agile team
· Predicting the approximate time, it will take to finish a project
· Enabling better sprint management
· Improving team productivity
· Conduct Stakeholder Interviews to define the end goal and features of the product/Project
· Define High-Level Product Backlog
· Understand the Client and its Potential Customers
· Prioritize Requirements – MOSCOW (MUST, SHOULD, COULD, WONT)
· Prepare the Minimum Viable Product (MVP) Backlog
· Choose an Agile estimation technique (Planning poker or Tshirt Sizing
· Plan the sprint
· Validate that your estimates are internally consistent among stories as you go along.
Q: Scrum master
Scrum Master is accountable for establishing Scrum as defined in the Scrum by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization. The Scrum Master is responsible for ensuring the team lives agile values and principles and follows the processes and practices that the team agreed they would use. The Scrum Master is accountable for the Scrum Team’s effectiveness. Scrum Master’s role is System-focused, unlike the Project Manager’s role, which is Business-focused
Q: Roles a Scrum Master Plays
· Scrum Team
- Coaching the team members in self-management and cross-functionality;
- Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done;
- Causing the removal of impediments to the Scrum Team’s progress; and,
- Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.
· Product Owner
o Helping find techniques for effective Product Goal definition and Product Backlog management;
o Helping the Scrum Team understand the need for clear and concise Product Backlog items;
o Helping establish empirical product planning for a complex environment; and,
o Facilitating stakeholder collaboration as requested or needed.
· The organization
o Leading, training, and coaching the organization in its Scrum adoption;
o Planning and advising Scrum implementations within the organization;
o Helping employees and stakeholders understand and enact an empirical approach for complex work; and,
o Removing barriers between stakeholders and Scrum Teams.
Q: Day of a Scrum Master?
· Organizing the meetings (refinement sessions, daily standup, sprint review, retrospective, sprint planning)
· Facilitating the team members solving impediments
– avoiding the pitfall to resolve the impediment yourself
– the team should be self-organizing / self-managing as much as possible
– the Scrum Master should do as little as possible
· Facilitating the Product Owner in fulfilling his role adequately
-Walking the product owner through more technical user stories
· Facilitate preparing and having the meetings
– the sprint review can often be done by team and PO
– the refinement meetings depend on the maturity of the team
– the sprint planning can often be done by the team
– the retrospective often needs good preparation and guidance to keep it inspiring and instructive
· Facilitate the team in following the Scrum process
Q: Scrum Master Challenges
· Difficulty in Maintaining Time-boxing
· Lack of Buy-in from Senior Management
· Agile Meetings not conducted correctly
· Lack of Agile Training
· Managing Changes in Scope
· Managing Distributed Teams
· Fear of Being Transparent
Q: Who is a successful scrum master?
A successful scrum master is one who has a clear understanding of both leadership and facilitation. As a scrum master, you need to know when to lead solutions and also when to simply facilitate the team to help them achieve their goals.
A successful scrum master is also someone who can help a team reach its full potential by encouraging and enabling its members. To be successful, you need breadth knowledge in respect of the product that you are helping your team to develop and also the market which that product falls in. Finally, you need to be a strong relationship builder and influencer.
Q: Leadership Vs Management?
· Management is all about controlling and directing the resources to that you have
· Leadership on other hand is about inspiring, motivating and influencing people to achieve your objective.
· To be a successful manager you need to have a perfect blend if these two.
Q: Serves Team?
· Promoting scrum events as and when requested by the PO
· Help PO in efficient Backlog management
· Help PO to understand agile principle and practices
· Assist PO to arrange the task in the product backlog to maximum value
· Help the Scrum team in adopting a shared vision
Q: Serves Organization?
· Act as agile change agent and coach
· Helps to increase the productivity of the scrum team
· Supports agile leadership principles and practices
· Help stakeholder and employees understand the scrum empirical theory
· Plan scrum implementation within the organization
Q: How would you facilitate the daily scrum?
The daily scrum meeting is absolutely vital in ensuring the team is focused on what they need to achieve. It is also vital in providing me the information and details on what is preventing the team from achieving its objectives.
On that basis, I would as 3 very specific questions during the scrum meeting
· What the team had achieved previous day
· What they are planning to achieve on that particular day
· What is preventing them from achieving their objectives.
To summarize, I would use the daily scrum meetings to focus the team and use my expertise and experience to influence and facilitate them towards the goal.
Q: How to build a successful remote scrum team
A remote scrum team should follow the core scrum tenants of clear communication, transparency, and a dedication for continuous improvement.
· Collaboration tools
· Be accessible to all team members
· Enable collaboration, sharing, and notifications to team members
· A collection of relevant, engaging information
· Jira is used for issue tracking, Confluence for team collaboration, and Trello is used to make lists and track progress.
· Impromptu chats
· Over-communicating decisions across all geographies
· Minimizing the friction in setting up the development environment
· Clearly defining the definition of done
· Creating guidelines for filing effective bug reports
· Daily scrum meetings
While agile promotes self-reliance and organization, it’s particularly important for remote team members to take ownership of work and expand that to the entire team. Team members can take responsibility for achieving business goals and how they are contributing to it. You can provide visibility by documenting expectations on a Confluence page and agree how to hold each member accountable.
Q: Adapt to the New Team?
· Observation – a week
· Product Backlogs
· Previous artifacts (Increments, Sprint backlogs, burndown charts, demo, Escalations, impediments)
· Team dynamics
· Light weight working agreements
· Sprint planning, daily scrum, retrospective
Fail fast & learn fast
Q: Conflict in the team?
· Identify the main cause of the issue. If you don’t know the exact reasons for the problem, then you cannot resolve it.
· Hold discussions, mostly during the daily scrum, to openly talk about the conflict and what the team could do to resolve it. (Who will take the responsibility of a story)
· Would explore different ways the team could resolve the conflict. It would be important at this stage to listen to both sides, understand the issues and look to stop it asap by ensuring everyone cooperated with the proposed resolution.
· Make agreement of a definite way forward for the team and regularly revisit the progress the team is making through open discussions during the daily scrum
· So, by A2C3
o Competing or
Q: Scrum of Scrum Conflicts
· First have to quantify the impact of those delays /defects affecting on our delivery. Overall impact should me made clear.
· Present it in the scrum of scrum meeting
· We should come to a common solution on how to prioritize the work and meet a common goal.
· Avoid direct confrontation with the scrum master and the management
· Apply NVC
Q: Handle underperformance?
· All the fingers are not the same
· Personal or Technical
· Underperformance is not a problem but its symptom of a serious problem.
· Arrange technical help
· Escalate to senior manager
Q: Unable to deliver or inconsistent velocity
· New team members are being hired
· Team members are leaving
· Working in uncharted territory
· Various levels of seniority in the team\working with legacy codes, undocumented
· Unexpected technical debt
· Unnecessary holidays and sick leaves
An impediment in Scrum is a factor that blocks the Development Team in its creation of a valuable piece of software in a Sprint, or that restricts the team in achieving its intrinsic level of progress.
· Unclear requirements
· Project infrastructure issues
· Project operational issues
· Illness of team members
· Unforeseen and undesired changes in team composition
· Issues with the tooling of the Development Team
· Scarcity of skills
· Lots of technical debt
· Problems with suppliers
· Unavailability of the Product Owner
· Undesired pressure from management
· Conflict between team members
· Lots of unimportant meetings the Development Team has to attend
· Restrictions to the team environment
· Removing impediments
· Don’t wait until the Daily Scrum to raise an impediment!
· Use a Sprint Goal. If something prevents the team from achieving the Sprint Goal, than it’s definitely an impediment.
· Understand the difference between ‘blocks’ and ‘impediments’. A block affects only a single task, whereas an impediment acts like a parachute, slowing down overall progress.
· Improve transparency by using an ‘Impediment Board’.
· Keep track of fixed impediments. This will provide great input for the Sprint Review and Sprint Retrospective.
· Understand the organization. A Scrum Master should understand the organizations culture. He should understand how things get done in the organization. By choosing the right approach, difficult impediments can be tackled easier.
· Be brave and creative in removing impediments. Be prepared to ask for forgiveness afterwards when you need to take bold decisions to ensure the Development Teams productivity.
· Collaborate with the Product Owner. Quite often impediments will be related to product management and collaboration with stakeholders and suppliers. The Product Owner is a key player on this area.
· Stop spending time and effort in solving the wrong problem.
Q: Anti-patterns in Scrum
· Flow Disruptions
· PO Assigning sub task to developers
· Defining technical solutions
· Lack of support
Q: Define success?
· Preforming my role in high standards
· Success is also getting the most out of my team by performing to high standards
· I will have my own personal and professional goals only if I perform well and when it happens it’s my success
· Success according to me is also see your organization achieve it commercial and financial objective
Q: Help the team pick stories
As scrum master, ensure that no secondary user stories are ranked above primary ones
To help the team:
· Include them in the initial planning stages
· Additional training to some team members
· Pair programming
Q: Scrum master responsibilities
Standups – Facilitate daily standups
Iteration/sprint planning meetings– Protect the team from over-committing and scope creep.
Sprint reviews – Participate in the meeting and capture feedback.
Retrospectives – Note areas for improvement and action items for future sprints.
Scrum Board administration – Work as the administrator of the scrum board.
1 on 1s Internal Consulting – Scrum masters should be prepared to consult with team members and internal stakeholders on how best to work with the scrum team.
Reporting – Regular analysis of burndown charts and other portfolio planning tools
Blockers – The scrum master aids the team by eliminating external blockers and managing internal roadblocks through process or workflow improvements.
Busy work – Scrum masters should be comfortable doing just about anything to help their team
Q: Improve as scrum master
· Accept feedbacks
· Be open minded
· Experiment with new suggestions
· Share your experience
· Organize seminar and conferences to gather knowledge
· Facilitate a fully dedicated retrospective meeting
Q: Process changes as a scrum master
· Server issue came up.
· Trigger is made to consistently connect & respond if fails
Scrumban is a project management framework that combines important features of two popular agile methodologies: Scrum & KanbanQ