Scrum Artifacts Flashcards
What part of the capacity of the Development Team does Product Backlog refinement usually consume?
Not more than 10%
Product Backlog refinement usually consumes no more than 10% of the capacity of the Development Team.
A Development Team is 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?
Make sure the dependency is visible in the Product Backlog and the Development Team has enough independent Items for the next Sprint.
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.
Development Teams should deliver an Increment of product functionality every Sprint.
Imagine the following situation. At the Sprint Retrospective meeting the Scrum Team identified some improvements that can be done. What should the Scrum Team do? Select the best option.
Make sure the Sprint Backlog for the next Sprint includes at least one high priority process improvement.
The Sprint Backlog makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal. To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting.
What technique should be used for representing Product Backlog Items?
Any technique, even a mix of several techniques
User stories are a fairly common technique for representing Product Backlog Items, but other techniques can be used instead. For instance, a team can use scenarios, use cases, acceptance tests, etc. The Product Backlog might even contain a heterogeneous mix of the above.
The Product Owner should work with the rest of the Scrum Team on choosing and optimizing the techniques used to represent Product Backlog Items.
How does Definition of “Done” help the Scrum Team? Select three most applicable items.
- DoD ensures artifact transparency
- Guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning
- DoD is used to assess when work is complete on the product Increment
- DoD is used to assess when work is complete on the product Increment
- Guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning
- DoD ensures artifact transparency
All Development Teams working on the same Product should use the same Product Backlog.
True
All Development Teams working on the same Product should use the same Product Backlog.
Every Product Backlog Item should be created by the Product Owner personally and only then the Development Team can add details to it at the PO’s discretion.
False.
The Product Owner is solely responsible and accountable for the decisions in the Product Backlog. However, the legwork of managing the Product Backlog might be fully delegated to the Development Team, so it is quite possible that the Product Owner might not ever create or write a User Story or Product Backlog Item.
Who has the “last say” on the order of items in the Product Backlog?
The Product Owner
While the Product Owner is not the only person who may influence the ordering of the Product Backlog, the Product Owner has the “last say” on the order of the Product Backlog, and those wanting to change the order of the Product Backlog have to influence the Product Owner to do so.
Who is responsible for all estimates in the Product Backlog?
The Development Team
The Development Team is responsible for all estimates in the Product Backlog. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.
What are the characteristics of a Product Backlog Item that is “Ready” for selection in a Sprint Planning? Select three.
- Somewhere at the top of the Product Backlog
- Well refined
- Can be “Done” within one Sprint
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.
Who is responsible for the Product Backlog?
The Product Owner
The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.
How long does the Product Backlog exists?
While the Product exists
The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. If a product exists, its Product Backlog also exists.
What two attributes are optional for a Product Backlog Item?
- Test descriptions that will prove PB Item completeness when “Done”
- Dependencies
Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when “Done”.
What are Product Backlog features? Select three.
- It is never complete
- As long as a product exists, its Product Backlog also exists
- It is dynamic
A Product Backlog is never complete. The earliest development of it only lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. As long as a product exists, its Product Backlog also exists.
What could be a source of requirements for any changes to be made to the product?
The Product Backlog
The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product.
