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

Strengths

·       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

Weakness

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.

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?

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

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

Agile Principles

Scrum

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

1.     Courage

Scrum team members have the courage to do the right thing and work on tough problems.

2.     Focus

Everyone focuses on the work of the Sprint and the goals of the Scrum Team.

3.     Commitment

People personally commit to achieving the goals of the Scrum Team.

4.     Respect

Scrum Team members respect each other to be capable, independent people.

5.     Openness

The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work.

Examples

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

1. What shall we continue?
2. What needs to be stopped?
3. 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.  

Q: Sprint

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

Measuring Deliverables

·       Sprint Goal Success: Cumulative flow diagram

·       Escaped Defects and Defect Density

·       Team Velocity: Velocity Chart

·       Sprint Burndown: Burndown Chart( work remaining)

Measuring Effectiveness

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

Product Quality

For e.g.:

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

1. The story should be written exactly in the ‘user story’ format.
2. Acceptance criteria must be understood by the team.
3. A Team needs to estimate the story.
4. The team should understand how to provide a demo of the features.
5. 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

·       Coded

·       Tested

·       Security Testing Done

·       Integrated

·       Regression

·       etc

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

Sprint:

Entry

·       We should have a refined, prioritized backlog.

·       The capacity of the team

·       The velocity of the team

·       Sprint backlog and DOR achieved

Exit

·       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 10^th day even if its half or full incomplete stories

Task

Entry

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

Exit

·       Goal related to the task is achieved

·       New->Assigned->In progress->Done

Feature

·       Entry

·       When we pick a user story for execution, the fearture is automactically entered

·       Exit

·       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

6.   Big/Uncertain/Small

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

·       Transparency ensures that aspects of the process that affect the outcome must be visible to those managing the outcomes. 

·       Inspection

·       The various aspects of the process must be inspected frequently enough so that unacceptable variances in the process can be detected.

·       Adaptation

·       The adjustment must be made as quickly as possible to minimize further deviation.        

Increase ROI for projects with Scrum

Q: Scrum Phases and Processes

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

Scope Creep

What

¨     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

Why

¨     PO is uncertain of the priority at the beginning.

¨     Requirement is coming from the management.

¨     Started the work without analyzing the risk or dependencies.

Calculation

Added/Removed Scope points/Committed story points = % of scope creep.

Manage

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

Q: Spikes

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

§  Feasible(possible)

§  Viable(workable)

§  Applicable (How relevant it is)

§  Practical (resources)

Steps in POC

¨     Prove the need.

¨     Problem – Solution mapping

¨     Prototyping

¨     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

In Agile:

§  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

·       Role

·       Influence

·       Interest/availability

·       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

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.

WHY

·       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

Process

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