Scrum Master Interview

Release Train Engineer (RTE)

a chief SM & coach of the Agile Release Train. -facilitate the ART events & processes & assist teams in delivering value. -communicate with stakeholders, escalate impediments, help manage risk, & drive relentless improvements.

SDLC: Software Development Life Cycle

a process that produces software with the highest quality & lowest cost in the shortest time possible. -a repetitive methodology. Ensure code quality at every cycle.

User Story INVEST: Small/Sized appropriately

smallest possible pieces.

3: Daily Scrum

team responsible for collaborating with each other.

SDLC: 2. Planning

the team determines the cost and resources required for implementing the analyzed requirements. It also details the risks involved and provides sub-plans for softening those risks.

What are Epics?

Epics are equivocal user stories or we can say these are the user stories which are not defined and are kept for future sprints.

Components of Burndown Chart

Horizontal axis: Your timeline — informed by the start and end date of your work period. This may display in days, weeks, or months depending on your team's cadence. Vertical axis: Your progress measurement. Most teams measure work in time, story points, or by the number of items to complete. Estimates: Your estimates determine where the trend lines start on the vertical axis. For example, if you estimated that this week's sprint will require 50 story points of work, then the trend lines will start at 50 on the chart. Ideal pace: Your ideal burndown line is a linear progression based on your timeline and work estimates. It represents the best-case-scenario rate of progress. Actual pace: Your actual burndown line represents your team's true rate of progress. It is based on actual work items being completed and is updated as you move along the timeline. Work completed: Some interactive burndown charts can highlight details of the work items that have been completed.

Do you see any disadvantage of using scrum?

I don't see any disadvantage of using scrum. The problems mainly arise when the scrum team do not either understand the values and principles of scrum or are not flexible enough to change.

SDLC: 1. Requirement Analysis

Identify the current problems by getting input from customers, stakeholders, salespeople, industry experts, and programmers. Learn the strength & weakness of the current system with improvement as the goal.

3: Daily Scrum: timebox

15 minutes

The Product Owner assigns tasks to Developers in the Daily Scrum, and the meeting always takes more than 15 minutes. How should the Scrum Master address this situation?

Convince the P.O. to stop assigning task to the Developers and not to participate in the daily scrum. The Developers themselves assign the tasks, rather than the Product Owner or the Scrum Master. The Daily Scrum is only for examining progress toward the Sprint Goal and planning work for the day.

3: Daily Scrum: Topic

Developers discuss: 1. What they accomplished yesterday? 2. What will be done today? 3. What impedes from meeting Sprint Goal.

3: Daily Scrum: Attendees

Dv (SM)

True or False: The Scrum Team can only pick up one high priority process improvement, identified during the Sprint Retrospective for working on in the upcoming Sprint.

False. At the team's discretion, high priority process improvements may be added to the Sprint backlog of the upcoming Sprint. If the team is able, they can pick up more than one.

What does Cone of Uncertainty show?

How much is known about the product over time.

When something about Scrum frustrates the Product Owner, they can delegate some responsibilities to the Scrum Master.

It is NOT acceptable for the PO to attempt to proxy or outsource their PO Scrum Team duties. The PO will work in concert with the Scrum Master to utilize Scrum correctly and advantageously and try to never been seen as subverting or disrespecting the Scrum framework. When something about Scrum frustrates a Product Owner, he/she should consult the Scrum Master for ways to implement the Scrum framework in a way that is effective.

Backlog Refinement: timebox

Max 2 hours

How many backlogs can a Product have?

Maximum 1 backlog per product. Products have one Product Backlog, regardless of how many Scrum Teams are working on that Product. Any other setup makes it difficult for the Developers to determine what it should work on.

Scrum Metrics: Workload Distribution

Measure of how much work is assigned to each scrum team member for the current sprint.

SAFE Metrics: Flow Efficiency

Measurement of the active and non-active time required to complete tasks. For example, if your flow efficiency is 20%, then work items spend 80% of the time waiting for review, approval, testing, etc.

A well-respected executive asks the Developers to add an "important" item to a Sprint that is in progress. What should the Developers do?

Notify the P.O. & Scrum Master of the executives wishes.

SAFE Metrics: Flow Velocity

Number of items completed in a given time period — similar to throughput in kanban.

Backlog Refinement: Attendees

Scrum team

Who is allowed to change the Sprint Backlog during the Sprint?

The Developer Explanation Only the Developers can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint, and it belongs solely to them.

1: Sprint Planning: timebox

max 8 hours

Backlog Refinement: purpose

to help the P.O. to get the top of the backlog refinement READY for sprint planning.

Backlog Refinement: Estimation

to introduce estimating user story, use planning poker.

Benefits of TDD

1. Find & fix defects before delivering software to stakeholders. 2. Test first, test all the time. 3. Quality is built-in w/o extra testing afterward. 4. Keeps code simple.

Which of the following best summarizes the value of agile?

Agile promotes flexibility by following an iterative and incremental lifecycle

SAFE Metrics: Flow Distribution

Amount of different types of work (e.g. new features versus bug fixes) completed over time.

Kanban Metrics: Queue Length

Number of items in a column on the kanban board. Queue length provides a view of how many items are sitting in each column over time.

Kanban Metrics: Blocked Time

Tally of tasks in progress that are reliant on issues or dependencies being resolved — and currently "blocked." Blocked time helps you understand any setbacks that occurred during a work period.

When to use Waterfall.

Waterfall is suited for situations with low volatility.

Bcklog Refinement: estimation: affinity grouping

a quick way to group stories into similar sized categories (xs, s, m, l, xl, ...)

How to manage Product Backlog?

1. Jira 2. Asana 3. Monday

4: Sprint Review: Agenda

1. Product DEMO 2. Stakeholder feedback 3. Change product backlog.

SDLC: Stages

1. Requirement Analysis 2. Planning 3. Architectural Design 4. Software Development 5. Testing 6. Deployment

Agile Frameworks:

1. Scrum 2. Extreme Programming (XP) 3. Lean Software Development 4. Kanban 5. Crystal 6. FDD: Feature-Driven Development 7. DSDM: Dynamic Systems Development Method 8. TDD: Test-Driven Development

SDLC: Architectural Design

1. Turning software specification into design specification. Stakeholders then review plan and offer feedback and suggestions. It's important have a plan for collecting and incorporating stakeholder input into this document.

1: Sprint Planning: topics

1. What = select PBIs 2. How= come up with task.

Product Backlog Hygiene Rules

1. backlog should not be too big (less than 100 PBIs) 2. top PBIs should be prioritized (the whole backlog doesn't have to be perfect) 3. delete PBIs no longer needed 4. PBIs not for current quarter, year should be on a wish list and deleted for now.

4: Sprint Review: Highlights

1. demonstrate shippable product increment. 2. declare PBIs that meet acceptance criteria & whether goals are met. 3. NOT DONE PBIs are moved back to the product backlog. 4. Listen to stakeholder feedback. P.O. may prioritize PB after this.

Backlog Refinement: what's discussed

1. estimation of efforts (estimation cards) 2. requirement clarification 3. decompose EPICs to user stories.

User Story

1. great user story follows the INVEST method. acceptance criteria

What are the characteristics of a Product Backlog Item that is "Ready" for selection in Sprint Planning?

1. somewhat at the top to the product backlog. 2. can be "Done" within one Sprint. 3. Well refined Explanation Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be "Done" within the Sprint time-box. Product Backlog items that can be "Done" by the Development Team within one Sprint are deemed "Ready" for selection in a Sprint Planning.

SDLC: 4. Software Development

1. the development starts. It's imperative to have proper guidelines in place about the code style and practices.

What's in the Product Backlog?

1. user stories 2. EPICS 3. Spikes 4. Bugs (recommended to list as a user story) 5. tasks

5: Sprint Retrospective: purpose

1. what's working? 2. what can be done differently?

Pair Programming

2 people share 1 work station, typically taking turns typing while the other pays attention & helps.

Sprint Retrospective Techniques

1.

12 Principles

1. Early & continuous delivery2. Welcome changing requirements3. Deliver working software early.4. Work together daily5. Trust them to get the job done.6. Face-to-face conversation7. Delivering incremental value to the customer.8. Sustainable development (constant pace)9. Continuous attention to technical excellence10. Simplicity11. Self-organizing teams12. Tunes & adjust behavior accordingly

5. Sprint Retrospective Techniques

1. Highlights & lowlights Retrospectives . 2. Always be learning retrospectives. 3. Surprised Worried Inspired Retrospectives. 4. Hands on Deck Retrospectives 5. Hero's Journey Retrospectives 6. Original 4 Retrospectives 7. Hopes & Fears Retrospectives 8. WRAP Retrospectives 9. Timeline Retrospectives 10. ...

4 Agile Values

1. Individuals & Interactions OVER processes & tools 2. Working Software/Product OVER comprehensive documentation 3. Customer Collaboration OVER contract negotiation 4. Responding to Change OVER following a plan

What is MVP in scrum?

A Minimum Viable Product is a product which has just the bare minimum required feature which can be demonstrated to the stakeholders and is eligible to be shipped to production.

The product owner for your team normally turns stakeholder requirements documents into tickets and asks you to estimate each. Are you okay with that procedure?

A Scrum Master should not accept such a procedure, as it's nothing more than a waterfall process dressed-up in a pseudo-agile methodology. If the entire organization is supposed to focus on delivering value to its customers, it is essential that any process involving "requirements" being handed down to the engineers by a JIRA monkey be abandoned. Instead, the organization should start including everyone in the product discovery process — thereby establishing a shared understanding of what needs to be built.

What is Scrum Sprint?

A Scrum sprint is a planning unit in which work is completed and ready for review. The duration depends on the size of the project & number of people working on it. Max 4 weeks.

How do you calculate a story point?

A Story point is calculated by taking into the consideration the development effort+ testing effort + resolving dependencies and other factors that would require to complete a story

How would you recommend following-up on action items?

A good follow-up practice is to start talking about the status of the action items of the last retrospective — before picking new ones. If actions item from the last retrospective haven't been accomplished, the scrum team needs to understand why they failed and prevent that failure from happening again.

Kanban Metrics: Throughput

A measure of work progress in a given time frame. It is essentially the same as velocity — but is measured by the number of tasks rather than time or story points. Throughput is one of the most common kanban metrics.

How do you deal with team members "cherry picking" tasks?

A scrum team should generally have autonomy in how its members choose to distribute tasks. Maybe the presumed "cherry picking" of tasks by individual team members is a crucial part of the team's path to performance. However, if team members complain about this happening, the scrum master needs to address the issue. Additional training might enable some team members to accommodate a greater variety of tasks. Or, perhaps, someone needs to be gently pushed out of their comfort zone so that they learn to choose different kinds of tasks than the kinds they currently choose.

What is a good reason for cancelling a sprint?

A sprint can be cancelled when the sprint goal no longer makes sense to pursue.

Definition of Done (DoD)

A team's checklist of all the criteria required to be met so that a deliverable can be considered ready for customer use. a. coding is done. b. code reviews are done. c. testing is done. d. unit test coverage above X% e. test automation coverage f. documentation is updated g. Product Owner accepted

A member of the Scrum team attended a trade conference and came across a feature idea that he felt should be present in the product he was working on. When should that idea be included in the product backlog?

After team member discusses idea with the P.O. Explanation The Product backlog is supposed to contain all the things that could potentially add value. If the team member can convince the Product Owner that the idea indeed adds value, it can be added to the backlog immediately. Prioritization and scheduling of the story can only take place after it is first put on the product backlog.

SAFE Metrics: Flow Predictability

Aggregate measure of how well agile teams are able to meet their objectives.

What is Agile?

Agile is a mindset, more like a way of thinking allowing us to embrace and adapt to change throughout the process of a product in order to deliver value to the customer.

When to use Agile model.

Agile is suited for complex and big projects.

The Product Owner wants two releases this quarter: one in the middle and one at the end. The Scrum Master points out that this does not matter. Why does the Scrum Master say this?

All increments should be (potentially) releasable, to improve the feedback loop and enable adaptation.

How do you handle team members that "lead" standups, turning the event into a reporting session for themselves?

All teams go through Tuckman's stages of group development: norming, storming, forming, performing. Scrum teams included. Although there are not officially any leadership roles within a scrum team, someone is likely to assume that role. This might happen because of his or her (technical) expertise, communication skills, or level of engagement. It's important, however, that this does not result in other team members reporting to this person. The Scrum Master must therefore be vigilant and intervene if necessary to ensure team members communicate — during standups or otherwise — as required by scrum.

Who should participate in a retrospective?

Although not mandatory, it's generally best practice to include the product owner in retrospectives — they are an important part of the "team", both practically and functionally. Some scrum teams, however, may not always want their product owners to participate — a team's wishes should be considered. Anyone else outside of the immediate scrum team, and particularly managers of team members, should not be invited to participate.

When is the Definition of Done used first by the Scrum Team?

During the estimation of the features in the Product Backlog, since the work depends on the requirements of both the Product Backlog items and the Definition of Done.

What kind of information would you require from the product owner to provide your team with an update on the product and market situation?

Any information suitable to provide the team, with an understanding why something is of value to customers. This may be of a quantitative nature, e.g. analytical data describing how a process is utilized. It also may be of a qualitative nature, such as transcripts, screencasts, or videos from a user testing session.

How do you prevent boredom during retrospectives?

Any of numerous possible variations may be used to prevent boredom during retrospectives. A different location; a different format; shortening or lengthening the allotted time box. Scrum masters can also use the team's choice of action items to encourage and structure discussions around the issues that the team themselves thus identified — creating engagement through acknowledgement.

The product owner of your scrum team tends to add ideas of all kinds to the backlog so to remember to work on them at a later stage. Over time, this has led to over 200 tickets in various stages. What's your take on this? Can a scrum team work on 200 tickets?

Any product backlog larger than the scope of two or three sprints is not manageable. Misusing a backlog by adding hundreds of items to it is a clear sign that the product owner needs help from the team to cope with the influx of ideas, suggestions, and requirements — and avoid misallocating resources. This support is what the candidate should offer.

Information Radiator

Artifacts used to help maintain transparency of a project status to team members and stakeholders.

How do you manage team members that consider standups to be a waste of time and who are therefore either late, uncooperative, or who simply don't attend?

As a first step, the Scrum Master might address the team member privately to discuss their reservations. Perhaps they just need more coaching or a longer training period to change their attitude. As a second step, the entire team could make it an issue during one or more retrospectives — and offer support to the team member. If there is still no change of attitude, a meeting with the team member and his or her manager is advisable. Finally, if no change can be achieved, the team member should be reassigned — potentially to another, probably non-agile team. Alternatively, a kanban team that would not force the team member out of their comfort zone could be tried. Scrum is not meant for everybody.

How often should members of the Developers change?

As needed, with the understanding that the team performance may take a short time hit.

A team was trying to estimate a story using the Planning Poker technique. Mary, a junior developer, felt the story deserved a story point of 20, whereas Tom, a senior developer, felt it should be 8. After 4 rounds of discussion, there was still no consensus. What should the Scrum Master do?

Ask the team how to proceed. Explanation The key principle in estimation is that the team needs to be comfortable with the estimate and should have bought into the estimate. There is a difference here that is seemingly hard to reconcile. The method to reach an agreement should also be determined by the team.

How do you deal with a product owner that assigns user stories or tasks to individual team members?

Assigning tasks to individual team members does not work at all and needs to be stopped. The assignment of user stories is the scrum team's prerogative. Preventing individual task assignment, if likely to occur, should be one of the Scrum Master's most pressing concerns.

Scrum Metric: Velocity

Average amount of work completed in a Sprint. Velocity helps agile development teams plan sprints, predict future milestones, and estimate a realistic rate of progress.

During a Sprint, if the Developers realize they can't complete the work planned, who should meet to review and adjust the Sprint scope?

During the sprint, scope can be re-examined and re-negotiated between the Product Owner and the Developers as more is learnt.

Can you draw an example of an offline kanban board for a scrum team right now?

Backlog In progress Code review Quality assurance Done Additional information may be included on or attached to any kind of board: Sprint or meeting dates User Acceptance Tests (UAT) A Definition of Ready A burndown chart (progress and work remaining over time) A parking lot (topics for future discussion).

Do you expect experienced team members to wait until the next standup to ask for help overcoming an impediment?

Certainly not. Waiting for the next standup delays progress. When facing impediments, if team members are waiting for the next standup before asking for help, it's likely that the "team" is more of a group — and the scrum master has team-building work to do.

SAFE Metrics: Competency

Complex measurement of the organization's commitment and follow-through on the core competencies of SAFe.

How do you measure the complexity or effort in a sprint? Is there a way to determine and represent it?

Complexity and effort is measured through "Story Points". In scrum it's recommended to use Fibonacci series to represent it.

What do you do in a sprint review and retrospective?

During Sprint review we walkthrough and demonstrate the feature or story implemented by the scrum team to the stake holders. During retrospective, we try to identify in a collaborative way what went well, what could be done better and action items to have continuous improvement.

If multiple Stakeholders have varied interests in the product and different viewpoints what is the best strategy for the Product Owner?

Do an intelligent balancing of interests and try to maximize the value of the product as a whole.

What is DoD? How is this achieved?

DoD stands for Definition of done. It is achieved when the story is development complete, QA complete, the story meets and satisfy the acceptance criteria regression around the story is complete the feature is eligible to be shipped / deployed in production.

The Product Owner and the Developers have disagreements in the Sprint Planning meeting. The Product Owner believes that the Developers have estimated the items too pessimistically and, therefore have selected too few items for the Sprint. Which is the best action for the Scrum Master?

Explain to the P.O. that its decision belongs to the Developers and that it should be accepted.

All the Scrum Teams working on the same product should have the same Sprint length.

False. Scrum does not require having aligned Sprints for multiple teams.

How to measure if Agile is working in your team & organization?

Few indications are: 1. An increase in software quality (less technical debt, less bugs, and generally better maintainability). 2.Increasing velocity of team & continuous improvement. 3. Increased participation of stakeholders in agile meetings, eg. Sprint review. 4. Working software delivered frequently.

During review, suppose the product owner or stakeholder does not agree to the feature you implemented what would you do?

First thing we will not mark the story as done. We will first confirm the actual requirement from the stakeholder and update the user story and put it into backlog. Based on the priority, we would be pulling the story in next sprint.

How do you facilitate user story selection in a way that the most valuable stories are chosen without overruling the team's prerogative to define their own commitments?

If a team is involved early enough in the process, for example by jointly creating user stories with the product owner, or during product discovery, any kind of guidance will be unnecessary. Most teams will often autonomously pick the best user stories for a given sprint. If a team resorts to "cherry picking" user stories during sprint planning, however, then the backlog refinement process needs to be seriously addressed, as the product owner is likely picking user stories that are not maximizing customer value.

Your team is picking reasonable action items but is later not delivering on them. How do you handle this?

If action items are picked but no one is later delivering on their commitments, the Scrum Master needs to follow up. If this is happening because of some impediment external to the team, the Scrum Master needs to address and eliminate the cause. The team can then catch up during a later sprint. However, if there is no external impediment, the problem is likely due to motivation, attitude, or personal issues within the team. In this latter case, the Scrum Master needs to provide those team members responsible with the encouragement or motivation necessary to overcome the problem and see that they deliver on their commitments. If the problem cannot ultimately be resolved, picking action items becomes a useless exercise — and the team will suffer as a result.

You are in the middle of a sprint, and suddenly the product owner comes with a new requirement. What will you do?

In ideal case, the requirement becomes a story and moves to the backlog. Then based on the priority, team can take it up in the next sprint. But if the priority of the requirement is really high, then the team will have to accommodate it in the sprint but it has to very well communicated to the stakeholder that incorporating a story in the middle of the sprint may result in spilling over few stories to the next sprint.

5: Sprint Retrospectives

Inspect & adapt the process. -to self-inspect/identify improvement opportunities and create a plan to put them into practice.

How would you coordinate between multiple scrum teams?

It depends on the size & coupling between those teams, and there are various frameworks for it. 1. SAFe -Scaled Agile Framework 2. LeSS-Large Scale Scrum 3. SoS-Scrum of Scrum

How do you measure the work done in a sprint?

It's measured by Velocity.

Why aren't user stories simply estimated in man-hours?

It's okay to use hours instead of points when the team and the organization can deal with it. However, some organizations will fall back into waterfall planning when work is estimated in hours. Estimating in hours might also be tricky when: legacy software is involved, the team is facing significant technical debt, or a team is composed of mostly junior members. Story points are more suitable in these situations because the points more accurately reflect both required effort and complexity. This is a result of points being used not only for estimation, but also as a means to measure and convey commitments and team velocity.

5: Sprint Retrospective: timebox

Max 3 hours

Do you check the team's health during a retrospective, or is doing so unnecessary? If you do, how would you go about it?

Measuring a team's health is a good way to get an idea about current levels of engagement and satisfaction and is a useful method for discerning trends. A simple scale from 1 (terrible) through 2 (poor), 3 (neutral), 4 (good), to 5 (excellent) will do the job — and requires just two minutes to complete.

So in scrum which entity is responsible for deliverable? Scrum master or Product owner?

Neither the SM or the PO. Its the responsibility of the team to deliver shippable increments.

Kanban Metrics: Work In Progress (WIP)

Number of tasks that have been started but not completed. WIP is one of the most common kanban metrics.

What is OKR?

Objectives and key results. Objectives: e.g., "Become the #1 social network for pets." Key Results- indicator telling us that goal was achieved. KR1. 1 million registered users by the end of Q4 KR2. NPS score over 65 KR3. Top positions in search results for pet social.

One week into a four-week sprint, the Developers have realized that they won't be able to deliver half of the Sprint Backlog items. The Product Owner is not happy with this, because the customer is expecting most of those features for a release at the end of the Sprint. What is the best course of action as the Scrum Master?

Recommend the P.O. to revise the order of Sprint backlog items and let the Developer continue with the best they can.

Agile metrics:

Scrum 1. Burndown chart 2. BurnUp Chart 3. Velocity 4. Workload Distribution Kanban 5. Blocked Time 6. Controlled Chart 7. Cumulative Flow Diagram 8. Cycle Time 9. Lead Time 10. Queque Length 11. Throughput 12. Work In Progress (WIP) 13. Work item age SAFE 14. Competency 15. Flow Distribution 16. Flow Efficiency 17. Flow Load 18. Flow Predictability 19. Flow Time 20. Flow Velocity

Can you give an example of where scrum cannot be implemented? In that case what do you suggest?

Scrum can be implemented in all kinds of projects. It is not only applicable to software but is also implemented successfully in mechanical and engineering projects.

How is scrum different from other iterative models?

Scrum is an interative model with incremental progress.

Scrum's foundation

Scrum is founded on empirical process control theory, or empiricism along with lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Lean thinking is about reducing waste and focusing on the essentials.

Do you think scrum can be implemented in all the software development process?

Scrum is used mainly for: Complex kind of project Projects which have early and strict deadlines When we are developing any software from scratch.

4: Sprint Review: Attendees

Scrum team (P,O, SM, & developers), Stakeholders, end-users, customers ...

1: Sprint Planning

Scrum team agrees to Sprint goals & negotiate which PBIs will be selected for the Sprint backlog. -P.O. prioritize product backlog, clarifies requirements, & acceptance criteria. -team estimates work. 60% of work should already be known.

How much capacity would you consider adequate for refactoring? Fixing important bugs? Exploring new technologies or ideas?

Setting aside the most critical and urgent tasks (such as the web site being offline), the 15-10-5 approach is generally a good rule of thumb: dedicate 15% of a team's capacity to technical debt, 10% to bugs, and 5% to explorative spikes. You may, of course, deviate from this when it comes to an individual sprint. But, generally, maintaining these allocations will satisfy the maintenance requirements of most software applications.

Jack wants to showcase a new color theme he's created for the product that is more consistent with the corporate branding. Which is the best forum to do this?

Sprint Review Explanation Sprint review is the best forum to showcase this because it allows you to showcase a working product and gather feedback from a large number of stakeholders at the same time.

Types of Burndown Chart

Sprint burndown chart: Shows the sprint progress of your agile development team. Release burndown: Gives a broader view of progress on all the product features and requirements that need to be completed for a product release. Epic burndown: Provides an even longer-range view of progress on work that may span multiple releases.

Would you recommend formal standups for all teams no matter their size or experience level?

Standups are an important part of scrum, but not all standups need to be formal. A small, experienced, collocated team may use a coffee break for their standup. However, taking that kind of relaxed approach to standups for a large team with several junior members would probably achieve nothing if it doesn't first descend into chaos. For large teams, a formal meeting is needed to provide format and guidance. For distributed teams who need to "dial in" and, for obvious reasons, can't meet for coffee, a formal standup is necessary insofar as the standup, due to technical constraints, must be scheduled and conducted in an organized fashion.

How do you approach standups with distributed teams?

Standups with distributed teams are not much different to standups with colocated teams — except that sharing board activity may require video conferencing when the team is working with offline boards that mirror each other. If you are using task management or planning software like JIRA (or any other cloud-based application), board updates are generally easy for each team member to follow on-screen. With such online software in place, a Skype call or Google Hangout may suffice.

Technical debt ...

Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution. In other words it can be defined as the longer term consequences of poor design decisions. Technical debt is a real risk which can genuinely be incurred. It compromises long-term quality of the Product. One of the ways of handling technical debt is recording it on the Product Backlog. So, it becomes visible to the Scrum Team.

SDLC: 5. Testing

Test for defects and deficiencies. Fix those issues until the product meets the original specifications.

Who is allowed to change the Product Backlog?

The P.O.

The Developers are waiting for a specific software component that they need to integrate and use.The component should be ready in a month.The Backlog Items with highest priorities depend on this specific component. What should the Product Owner do?

The Product Backlog should make the dependency visible to all the interested parties. Usually Items with external dependencies are not considered "Ready" for selection at the Sprint Planning. Developers should deliver at minimum, one Increment of product functionality every Sprint.

A Product Owner came across a product idea that is unlikely to be prioritized for work in the near future. How should the Product Owner deal with this issue?

The Product Owner needs to add a placeholder story. Writing a story is important to capture the idea. Going into details is not advised because the story is unlikely to get prioritized in the near future.

The Product Owner should be expertly aware of the marketplace for the product.

The Product Owner should be expertly aware of the marketplace for the product. They should constantly be gathering and re-gathering information and data regarding the marketplace, so that the product value is maximized. Getting out of touch with the marketplace can be a recipe for product disaster.

What is the role of the Scrum Master in the Daily Scrum?

The Scrum Master's role is to ensure the meeting is held, and kept to within 15 minutes. They don't facilitate discussions. Also, the "3 questions" format is no longer mandated with the 2020 version of the Scrum Guide.

A user story is lacking the final designs, but the design department promises to deliver on day two of the upcoming sprint. The product owner of your scrum team is fine with that and pushed to have the user story put in the sprint backlog. What's your take?

The answer to this depends upon the team's situation and experience: If the design department will definitely deliver (because they have done so in the past); if the user story is high value and can be accomplished within the sprint despite its UI deliverables arriving late; and if the team agrees — it's probably an acceptable exception. Beware, however, that this kind of exception does not become the "new normal" — allowing the organization to bypass the backlog refinement and sprint planning process. The candidate should be aware that such a situation would not be tenable. Furthermore, if implementation of a user story subjected to such an exception fails, no one will bother to read the fine print and acknowledge that an exception had been made; instead, they will most likely view the agile process itself as having failed. Candidates may either accept or reject exceptions to the agile process, but they should be able to analyze the situation and explain the collateral damage that the scrum team may be exposed to.

A team is working on a cutting-edge technology, and does not have a lot of familiarity with the technical environment. As a result, it is struggling to estimate a complex story because the approach itself is not clear. How should the team proceed?

The best way to remove uncertainty of a technical nature is to perform experimentation - which is the intent of a SPIKE story. When a story cannot be estimated because the team needs to experiment, the best approach is to write a spike story before working on the main story.

The burndown chart for a team showed a peculiar trend. It started dropping rapidly at the beginning of the Sprint, and then seemed to plateau in the middle. A day before the Sprint, the line dipped rapidly and reached the horizontal axis. Which of the following are likely reasons for this trend?

The burn down chart reaching a plateau (i.e. remaining flat) means tasks are not finishing, which is likely when there is a blocking issue or updates are not being made to the sprint board regularly.

Tell me one big advantage of using scrum?

The major advantage which I feel is - Early feedback and producing the Minimal Viable Product to the stakeholders.

Agile Planning

The most important aspect of the Agile project (planning onion: different layers of planning) 1. strategy 2. product vision 3. release planning 4. sprint planning 5. daily planning

What is cadence:

The number of days or weeks a sprint, iteration, or release lasts. The freedom to decide the cadence of your planning meetings and the lengths of cycles between those plannings. *the longer the cadence, the closer it becomes a waterfall. Do it frequently.

The Sprint Retrospective.....

The purpose of the Sprint Retrospective is to: Inspect how the last Sprint went with regards to individuals, interactions, processes, tools and the Definition of Done. It is the last event that concludes the Sprint.

How can you as a Scrum Master contribute to sprint planning in such a way that the team is working only on the most valuable user stories?

The scrum team should never select user stories according to any kind of ranking established by the product owner or anyone else. Sprint planning is determining the most efficient path to value creation. The best way to accomplish this is to ensure that: The scrum team is involved in the product discovery process at an early stage. The product backlog refinement process is well understood by both the scrum team and the product owner. (This can be supported, for example, by the creation of a "Definition of Ready" standard for user stories.) All user stories are created in a collaborative effort between the product owner and the scrum team. (A shared understanding and joint ownership is the goal.)

A Scrum Team had planned for 10 stories to be completed in a Sprint. The Developers have completed coding and unit testing on the stories and they have been integrated in the build system. There are 12 outstanding bugs reported during testing. Some of them block the paths described in the stories but none of them are showstoppers. How does one determine if this Sprint is successful or not?

The team should check against the DoD that it agreed upon at the beginning of the Sprint.

The standups of your scrum team are not attended by any stakeholder. How do you change that?

This can quickly turn into a philosophical discussion. Should stakeholders be allowed to participate in daily scrums? If they do, is it a form of reporting — circumventing scrum rules? If some adaptation of scrum is working in your organization — that's a good thing. Don't rule out stakeholders being allowed to participate in the daily standups if the team is okay with that. In fact, if stakeholders attend standups regularly, this will invariably and significantly improve communication between the team and the stakeholders — another good thing. But how does a Scrum Master encourage stakeholders to attend standups? Make it worth their while. A Scrum Master can do this in any number of ways. They might offer stakeholders the opportunity to learn early details of a new product or feature if they attend. They might also choose to give stakeholders the opportunity to ask questions of the engineers directly, without going through the product owner.

Kanban Metrics: Work Item Age

Time a task has existed from when it was created to the current point in the work period. While cycle time and lead time measure work that has been completed, work item age looks at work still in progress.

Kanban Metrics: Cycle Time

Time spent actively working on a feature from start to finish, including time spent on reopened issues. Cycle time is one of the most common kanban metrics.

SDLC: 6. Deployment

To deploy software to the production environment so users can start using the product. Many organizations choose to move the product through different deployment environments such as a testing or staging environment. This enable stakeholders to safely play with the product before releasing it to the market.

Backlog Refinement: Grooming

To get a better understanding of upcoming work & decompose PBIs to smaller PBIs.

SAFE Metrics: Flow Time

Total time a feature exists from initial creation to customer delivery — similar to lead time in kanban.

Kanban Metrics: Lead Time

Total time a task exists — from the moment it is created until work is completed.

SAFE Metrics: Flow Load

Total work in progress across all stages — similar to WIP in kanban.

Bcklog Refinement: Estimation: planning poker

Used to estimate effort. a poker card with Fibonacci sequence (0+1 = 1, 1+1 = 2, 1+2= 3, 2+3=5, 3+5=8, 5+8=13...) once team is clear on work, they vote on it. an outlier will have the opportunity to explain and another vote is taken .

Kanban Metrics: Cumulative Flow Diagram

Visualization of completed work over time, similar to a burnup chart. Cumulative flow diagrams use color-coding to represent different statuses (e.g., in progress, done, in backlog).

Kanban Metrics: Controlled Time

Visualization of the amount of time spent working on different features during a work period — informed by cycle time and lead time. Control charts help kanban teams predict future performance.

Apart from planning, review and retrospective, do you know any other ceremony in scrum?

We have the Product backlog refinement meeting (backlog grooming meeting) where the team, scrum master and product owner meets to understand the business requirements, splits it into user stories, and estimating it.

When does a Sprint conclude?

When the Sprint Retrospective is complete.

What retrospective formats have you used in the past?

With retrospectives, one size does not fit all. Consequently, there are various retrospective formats in common use: The classic format: What did we do well? What should we have done better? The boat format: What's pushing us forward? What's holding us back? The starfish retrospective: Start doing ... Do less of ... Do more of ... Stop doing ... Continue doing ...

Is it possible that you come across different story point for development and testing efforts? In that case how do you resolve this conflict?

Yes, this is a very common scenario. There may be a chance that the story point given by the development team is, say 3 but the tester gives it 5. In that case both the developer and tester have to justify their story point, have discussion in the meeting and collaborate to conclude a common story point.

In case, the scrum master is not available, would you still conduct the daily stand up meeting?

Yes, we can very well go ahead and do our daily stand up meeting.

User Story INVEST: Valuable

bring some value to the user.

Refactoring

changing the internal structure of a software to make it easier to understand & cheaper to modify w/o changing its external behaviors. improve the quality of software product to make it easier to change.

User Story INVEST: Estimable

estimate by understanding exactly what needs to be done.

Information Radiators

helps team be transparent by showing big visuals in team workspace of critical information on the team's progress. 1. For team: team norms & DoD. 2. For Customers: teams progress towards their commitment: burndown/burnup charts.

4: Sprint Review:

inspect & adapt the product. -team demonstrates attempt to build a potentially shippable product increment.

What is Waterfall?

is a linear approach to project development. A step is completed before the next. [evaluation, requirements, analysis, design, development, validation, deployment]

What is Scrum?

is an agile-framework within which people can address adaptive problems, while productively & creatively delivering high-value products.

TDD: Acceptance Test

is an automated teat that validates you've completed the implementation of a user story. Timescales is in days. Stories are small enough to get them done in days.

TDD: Unit Test

is an automated test that validates a single focused small element of the behavior of a story. Timescale is minutes.

Sprint Retrospectives

is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted in the future.

TDD: Test Driven Development)

is the practice of writing automated test first before any production codes. 2 Scales of TDD. 1. Acceptance test. 2. Unit test

Scrum Metric: Burndown Chart

it shows the amount of work completed against the amount of work remaining — measured in time, story points, or number of tasks.

4: Sprint Review: Scrum Master

keep a list of PBIs to add to product backlog. -stakeholder complaints should be directed to P.O.

User Story INVEST: Independent

keep stories as independent as possible.

EPIC

large body of work. High level of planning.

4: Sprint Review: Timebox

max 4 hours

User Story INVEST: Negotiable

new ways to solve the problem. Scope is negotiable {the "how" of user stories}

How do you track your progress in a sprint?

progress is tracked by a "Burn-Down chart".

Bcklog Refinement: Velocity

rate at which team can complete work in a give timeframe (during a Sprint). Number is created based on the number of story points delivered in each Sprint. Sprint 1 =16, Sprint 2=15, Sprint 3=17: 16+15+17=48/3=16 (assigned during planning poker)

The Product Owner of a team was asked for a forecast for the completion of a product release. There were 140 story points worth of work remaining in the project. The team's average velocity in the past 3 Sprints has been 65, though the best Sprint among the last three had a velocity of 85 story points. What should the Product Owner say?

the team will need about complete 3 more Sprints to complete the release.

3: Daily Scrum: Sidebar Topics/Parking Lot

things to discuss after daily scrum is over (volunteer meeting).

User Story INVEST: Testable

understand how to test product.

Definition of Ready (DoR)

understand whether story is ready for development. a. user story has acceptance criteria b. user story matches INVEST criteria c. UX design is done. d. No blocks or dependencies e. story is estimated.

5: Sprint Retrospective: Scrum Master

use status leveling techniques to reveal greater cross-section of viewpoints from team . 1. safety check (to create a safe environment) 2. focused https://www.dxn2u.com/conversation principles 3. basic retrospectives

Spikes

work items that result in new knowledge (investigation, research, experimentation, and learning). *consider a spike when there's a need to investigate a new technology, learn a new programming language, do prototyping, experimentation, and user research.