Scrum Team - Developers Flashcards
How do Developers estimate PBI size?
1️⃣ Absolute estimation – Time-based (e.g., “9 hours of work”)
2️⃣ Relative estimation – Story points or T-shirt sizing
3️⃣ Flow metrics – Based on past team performance (e.g., throughput)
4️⃣ Right sizing – Ensures PBIs are small enough for one Sprint
Why is creating transparency in the Product Backlog challenging?
✅ PBIs vary in detail and vagueness—some are high-level placeholders, while others are refined.
✅ Large PBIs often break down into smaller PBIs as they are refined.
✅ The actual effort required to complete a PBI is uncertain until work is done.
What are levels of decomposition, and how can they help with transparency?
Levels of decomposition categorize PBIs by size and vagueness.
Common decomposition levels:
1️⃣ Epic – A large PBI that may contain multiple Features.
2️⃣ Feature – A mid-sized PBI that may contain multiple smaller PBIs.
3️⃣ PBI – The smallest, most actionable backlog item.
The choice of decomposition levels should fit the team’s needs—simplicity increases transparency.
What is the risk of adding too many decomposition levels to a Product Backlog?
Too many levels can make the backlog overly complex and harder to understand.
Simplicity creates transparency—only add levels if they improve clarity.
How should teams view the Product Backlog?
✅ Every item in the Product Backlog is a hypothesis of value.
✅ The team should strive for a minimally sufficient backlog—enough detail to work efficiently, but not excessive complexity.
✅ PBIs emerge and evolve over time through refinement and learning.
What is the Definition of Done?
A formal description of the state of the Increment when it meets the quality measures required for the product.
When is an Increment considered born?
The moment a Product Backlog item meets the Definition of Done.
How does the Definition of Done create transparency?
It provides a shared understanding of what work was completed as part of the Increment.
What happens if a Product Backlog item does not meet the Definition of Done?
It cannot be released or presented at the Sprint Review and returns to the Product Backlog.
What must Scrum Teams do if the Definition of Done is an organizational standard?
They must follow it as a minimum requirement.
What happens if there is no organizational Definition of Done?
The Scrum Team must create a Definition of Done appropriate for the product.
Who is required to conform to the Definition of Done?
The Developers.
What must multiple Scrum Teams working on the same product do regarding the Definition of Done?
They must mutually define and comply with the same Definition of Done.
When is it most appropriate for Developers to change the Definition of “Done”?
During each Sprint Retrospective:
Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of “Done”
When Developers determine that they have over-committed themselves for a Sprint, who have to be present when reviewing and adjusting the Sprint work selected?
The Product Owner and the Developers
How much of the Sprint Backlog must be defined during the sprint Planning meeting?
Enough so the Developers can create its best forecast of what it can do, and to start the first several days of the Sprint
Who determines when it is appropriate to update the Sprint Backlog during a Sprint?
The Developers
Who is responsible for ensuring that the new increments meet the Definition of Done?
The Developers
Who creates a Product Backlog item’s estimate?
The Developers after clarifying requirements with the Product Owner
Who is responsible for conducting the Daily Scrum ?
The Developers
Why does the Daily Scrum take place at the same time and place?
The consistency reduces complexity
How should teams ensure Non-functional requirements are consistently addressed?
By integrating them into the Definition of Done (DoD), ensuring they are met in every Sprint.
How should non-functional requirements be managed over time?
They should be regularly refined and reviewed to remain relevant and aligned with product and user needs.
How should Developers plan for non-functional requirements in a Sprint?
By considering the effort required to meet them, including time for performance, security, and scalability improvements.
How can NFRs be validated throughout development?
Through continuous integration and testing, including performance testing, security audits, and usability evaluations.
Why should Developers collaborate with stakeholders on NFRs?
To understand priorities and specifics, ensuring alignment with user expectations and business goals.
What should Developers do if an NFR cannot be fully achieved in one Sprint?
Aim for incremental improvement, making continuous progress over multiple Sprints.
How does ensuring NFRs align with Agile principles?
It supports building products incrementally and iteratively, with a strong focus on quality at every step.
During a Sprint, when is new work or further decomposition of work added to the Sprint Backlog?
As soon as possible after they are identified
