• Q-A product's first release is composed of increments from the last 7 Sprints.

When
reviewing the release for the first time, the stakeholders show surprise and state that
it is not what they expected and did not meet their needs. What may have led to this?
There are many potential causes for this situation. Some possibilities include:
• 1. The team may not have had a clear understanding of the stakeholders' needs.
• 2. The team may have misunderstood the requirements or had a miscommunication
about the scope of the project.
• 3. The team may have underestimated the complexity of the project.
• 4. The team may have failed to anticipate the potential for errors or unforeseen issues.
• 5. The team may have lacked the necessary resources or expertise to complete the
project as expected.
• 6. The team may have been too optimistic about the timeline and the amount of work
that could be completed in the allotted time.
• 7. The team may have been unclear about the roles and responsibilities of each team
member.
• 8. The team may have implemented the wrong technology or tools for the project.
• Product Backlog Items (PBIs) can be elaborated/broken down using single or multiple u s e r stories. In a
real-world scenario, two Product Backlog Items (PBIs)in Product Backlog has the following description
entered by the Product Owner
• A.PB1: "An HR Manager can view and see applications for the job posted by him".
• B. PB2: "A content creator can add content for marketing to his blog'"Write 2 user stories each for these
case scenarios along with acceptance criteria.Make assumption as appropriate.
• User story A1: As an HR Manager, I want to view and see applications for the job posted by me So that I
can review the applications and select the best suitable candidate
• Acceptance Criteria:
• 1. HR Manager should be able to log in to the system
• 2. HR Manager should be able to view all applications for the job posted by him
• 3. HR Manager should be able to filter the applications based on the job criteria
• 4. HR Manager should be able to view the details of the applications submitted
• User Story A2:As an HR Manager, I want to update the job posting information So that I can provide the
most up-to-date information to the applicants
• Acceptance Criteria:
• 1. HR Manager should be able to log in to the system
• 2. HR Manager should be able to view all job postings
• 3. HR Manager should be able to edit the job postings
• 4. HR Manager should be able to delete any job postings
• User Story B1: As a content creator, I want to add content for marketing to my blog So that I can
reach more potential customers
• Acceptance Criteria:
• 1. Content creator should be able to log in to the system
• 2. Content creator should be able to create new blog posts with marketing content
• 3. Content creator should be able to edit the blog posts
• 4. Content creator should be able to delete any blog posts
• User Story B2: As a content creator, I want to share my blog posts with other social media platforms
So that I can increase the reach of my blog posts
• Acceptance Criteria:
• 1. Content creator should be able to log in to the system
• 2. Content creator should be able to view all blog posts
• 3. Content creator should be able to share any blog posts to other social media platforms
• 4. Content creator should be able to track the views and shares of the blog posts on other social
media platforms
• Q-Your team's Product Owner approaches you for a word in private. She expresses some concerns she
has about the team's commitment and productivity. She has noticed that comparable teams within the
development organization have a higher average velocity. How would you handle this situation?
• First, I would thank the Product Owner for bringing up her concerns and for taking the initiative to
discuss them with me. I would then try to understand the underlying causes of the team’s low
performance and discuss potential solutions with the Product Owner. I would also explain that the
variables impacting velocity are unique to each team and may not be comparable to other teams in the
organization. Finally, I would ensure that the team is engaged in the process and that their suggestions
are taken into consideration when creating actionable plans to improve the team's velocity.
• Q-What is the difference between Product Vision and Product Roadmap? Make appropriate
assumptions and create a Product Vision for your chosen product ideausing the Product Vision Board?
• Product Vision and Product Roadmap are two distinct tools for product planning. A Product Vision is a
high-level, long-term goal for a product or a product line. It is a statement that conveys the purpose and
direction of a product or product line. It guides the direction of the product, and helps to create a
shared understanding of the product’s purpose and value.
• A Product Roadmap is a plan that outlines the timeline, features, and deliverables of a product. It
provides a visual overview of the product’s development and a timeline that can be adjusted as needed.
• Product Vision Board is a tool used to define and document a product vision. It is a canvas that helps
product teams visualize the Product Vision. It is typically composed of three columns: Purpose, Goals,
and Features. The Purpose column outlines the main purpose of the product, the Goals column outlines
the desired outcomes, and the Features column outlines the features and functionality needed to
achieve the desired outcomes.
• An example Product Vision Board for a product idea of a mobile grocery
delivery app may look something like this:
• Purpose: To provide customers with a convenient and reliable way to
order groceries and have them delivered to their door.
• Goals:- Increase customer satisfaction by providing quick and reliable
delivery.- Increase customer loyalty by providing quality products and
exceptional customer service.- Improve operational efficiency by
streamlining the ordering and delivery process.
• Features:
• - Easy to use mobile app for ordering groceries.- Real-time tracking of
orders.
• - Grocery delivery within a specified time frame.
• - Payment processing for secure transactions.
• - Customer support for any questions or concerns.
• Q-How is DevOps different than Agile? What business issues DevOps addresses?
• DevOps is different than Agile in that DevOps is an approach to software development that is focused on
collaboration between developers, operations, and other stakeholders. This collaboration enables teams to
build, test, deploy, and maintain applications more quickly and efficiently than with traditional methods.
• The main business issues that DevOps addresses are increasing the speed of software development and
deployment, improving quality, reducing risks, and increasing customer satisfaction. DevOps also helps
organizations reduce costs, as it increases efficiency and reduces the time needed to deliver products.
Additionally, DevOps helps organizations to quickly respond to customer feedback and market changes, as
well as easily scale their applications as needed.
• Q-The Scaled Agile Framework® (SAFe®) is a set of organizational and workflow patterns for implementing
agile practices at an enterprise scale. The framework is a body of knowledge that includes structured
guidance on roles and responsibilities, how to plan and manage the work, and values to uphold.
• SAFe promotes alignment, collaboration, and delivery across large numbers of agile teams. It was formed
around three primary bodies of knowledge: agile software development, lean product development, and
systems thinking.
• As businesses grow in size, SAFe provides a structured approach for scaling agile. There are four
configurations in SAFe to accommodate various levels of scale: Essential SAFe, Large Solution SAFe, Portfolio
SAFe, and Full SAFe.
• Dean Leffingwell and Drew Jemilo released SAFe in 2011 to help organizations design better systems and
software that better meet customers’ changing needs. At that time, teams used traditional project
management processes to deliver software. But as the need to rapidly respond to changing market
conditions increased, new frameworks emerged to help businesses improve solution delivery across their
enterprises, and SAFe was born. Today, SAFe is one of the most popular scaled agile delivery frameworks,
and SAFe’s worldwide community of practitioners continue to evolve it.
• Core principles and values
• Core Values- SAFe’s core values describe the culture that leadership needs to foster and how people
should behave within that culture in order to effectively use the framework.
• Alignment- SAFe requires that companies put planning and reflection cadences in place at all levels
of the organization. With these in place, everyone understands the current state of the business,
the goals, and how everyone should move together to achieve those goals. By synchronizing people
and activities regularly, all levels of the portfolio stay in alignment. Information flows both upward
and downward in a timely fashion, unlike traditional top-down, command and control structures.
• Built-in quality-In the SAFe framework, agility should never come at the cost of quality. SAFe
requires teams at all levels to define what “done” means for each task or project and to bake
quality development practices into every working agreement. According to SAFe, there are five key
dimensions of built-in quality: flow, architecture and design quality, code quality, system quality,
and release quality.
• Transparency-SAFe encourages trust-building behavior, including planning work in smaller batch
sizes so problems can be surfaced sooner, providing real-time visibility into backlog progress across
levels, and inspect and adapt rituals.
• Program execution-Program execution is the heart of SAFe and powers everything else in the
framework. Teams and programs must be able to deliver quality, working software and business
value on a regular basis.
• Leadership- SAFe requires lean-agile leadership behavior because only leaders can change the
system and create the environment necessary to embrace all of the core values.
• SAFe Principles
• The Scaled Agile Framework’s principles are meant to improve the company as a whole by inspiring lean-agile decision
making across functional and organizational boundaries. The principles are intended to influence the decisions of not just
leaders and managers, but of everyone in the organization and condition their mindset to shift from traditional waterfall
thinking to lean-agile thinking, where practices like Lean Portfolio Management are applied.
• Principle #1 Take an economic view: Inspired by the theories on product development flow from Donald Reinertsen's best
selling books, achieving the shortest sustainable lead-time requires each individual in the decision-making chain to
understand the economic implications of delays. Delivering early and often isn’t always enough. According to SAFe,
sequencing jobs for maximum benefit, understanding economic trade-offs, and operating within lean budgets are all
responsibilities that need to be shared throughout the organization. Many of the concepts and tools are drawn from
Reinertsen’s theories on product development flow.
• Principle #2 Apply systems thinking: SAFe encourages people using the framework to apply systems thinking to three key
areas: the solution itself, the enterprise building the system, and the value streams. Solutions can refer to products,
services, or systems delivered to the Customer, whether they are internal or external to the Enterprise.
• Principle #3 Assume variability; preserve options: By default, designing systems and software is an uncertain exercise. This
principle addresses uncertainty by bringing in the concept of set-based design, which calls for retaining multiple
requirements and design options for a longer period in the development cycle. The set-based design also relies on empirical
data to narrow the focus on the final design option further in the process.
• Principle #4 Build incrementally with fast, integrated learning cyclesSimilar to Principle #3, this principle addresses risk and
uncertainty through learning milestones. It is not enough for each component part of the system to prove functional, the
whole system must be considered to assess the feasibility of the current design choices. Integration points must be planned
on a regular cadence to accelerate faster learning cycles. These integration points are an example of Walter A Shewhart’s
plan-do-check-adjust cycle, a framework for continuous quality improvement and mechanism for controlling the variability
of development. Shewart's work and the work he inspired are often within SAFe.
• Principle #5 Base milestones on objective evaluation of working systems: Demonstration of an actual
working system provides a better basis for decision making than a requirements document or some other
superficial evaluation of success. Including stakeholders in those feasibility decisions early on supports
trust-building and systems thinking.
• Principle #6 Visualize and limit Work in Process (WIP), reduce batch sizes, and manage queue lengths:
Limiting work in process helps stakeholders see exactly how work is playing out.
• Principle #7 Apply cadence, synchronize with cross-domain planning:Agile teams naturally apply cadence
through sprints or iterations. Creating a cadence for all possible matters reduces complexity, addresses
uncertainty, builds muscle memory, enforces quality, and instills collaboration. Synchronizing these
cadences enables the people and the activities to move like cogs in the wheel where learned information
informs decisions and incremental planning.
• Principle #8 Unlock the intrinsic motivation of knowledge workers:Inspired by influential management
consultant Peter Drucker and author Daniel Pink, this principle is one of our favorites! It's about unleashing
the potential of teams and helping leadership take the perspective of coaching and serving their teams
over a command-and-control mindset.
• Principle #9 Decentralize decision making:Reducing queue lengths and taking an economic approach by
decentralizing decision making, gives teams the autonomy they need to get work done. Leaders should
preserve their decision-making authority for topics of strategic importance and enable teams to make
informed choices on everything else.
• Q- How does SAFe Work?
• Organizations that are ready to implement SAFe usually have executive-level sponsorship,a strong purpose
for change, and a foundation in Scrum.
• Q- 3 reasons why user stories are better than requirements: (i) They are more detailed.
It explains different ask of the client. (ii) It provide more clarity as it covers different
scenerios and are more exhaustive (iii) They are easier to understand by different team
members, helping in better collaboration & coordination among the team
• Q- What is sprint burndown chart and what is its significance?
• It is one of the agile metric to measure the productivity of the team. It displays the no of
sprints completed so far and the no of pending sprints to complete the work. It gives a
complete picture to the client on the progress made so far. It helps in determining the
pain points of developers & where they are lacking to deliver on time
• Q- Based on avg velocity of 50 points, PO estimates new feature would require 5 sprints
to deliver. The team realises they have completed 3 sprints with avg 30 stories and they
require additional 6 sprints. What to be done now?
• Ans- PO should keep the product backlog updated. The team should convey the change
in lead time to the client. Through the client, the PO can prioritize story points and
arrange them accordingly in sprints as per current velocity. For independent tasks, the
team size Can be increase to speed up the deliver. The scrum master should oversee the
newly defined sprints and make sure the team is adhering to the newly set timelines