ch 5 new qs for questions(shorter) number 3.docx
Document Details
Uploaded by Deleted User
Tags
Full Transcript
**Use Cases**: A use case describes **how a system interacts** with external entities (like users or other systems) to achieve a specific goal. It typically includes detailed steps of interactions, preconditions, postconditions, and alternate flows. **User Stories**: A user story is a **short,...
**Use Cases**: A use case describes **how a system interacts** with external entities (like users or other systems) to achieve a specific goal. It typically includes detailed steps of interactions, preconditions, postconditions, and alternate flows. **User Stories**: A user story is a **short, informal description** of a feature or function from the perspective of the end user. It is often phrased in a simple format that emphasizes user needs and outcomes rather than system interactions. **Level of Detail** - **Use Cases**: - More **detailed** and formalized. - Captures **step-by-step interactions** between the system and the user, including alternate flows and edge cases. - Focuses on **system behavior** and can include system responses to various inputs, error conditions, and variations. - **User Stories**: - Simple, **concise**, and less formal. - Focuses on **what the user needs** without specifying how the system achieves it. - Serves as a **placeholder** for future discussion (often during sprint planning or backlog refinement) rather than a complete specification. **4. Focus** - **Use Cases**: - System-centric and typically focuses on **how** a system will behave to fulfill a requirement. - Includes interactions, inputs, and outcomes to achieve a certain **goal**. - **User Stories**: - User-centric, focusing on **why** the feature is needed from the **user\'s perspective**. - Emphasizes **user value** rather than the detailed technical behavior of the system. 1. **Clear Criteria**: The DoD includes specific, measurable conditions that the work item must satisfy. These criteria ensure that all team members have a consistent understanding of what "done" means. 2. **Consistent Application**: The DoD is applied consistently across all tasks or features to ensure uniform quality and completion standards. Every feature, user story, or product increment must meet the DoD before it can be considered done. 3. **Shared Understanding**: The DoD is usually defined collaboratively by the development team, product owner, and sometimes other stakeholders. It reflects the team\'s quality standards and ensures transparency across the project. - **Ensures Quality**: The DoD helps ensure that work delivered meets certain quality standards, preventing half-finished or poorly implemented features from being released. - **Avoids Miscommunication**: It prevents misunderstandings between team members and stakeholders about what constitutes \"done,\" helping to manage expectations clearly. - **Promotes Consistency**: It promotes a consistent approach to work across the team, ensuring that every item in a sprint or release meets the same standards. - **Increases Predictability**: A well-defined DoD allows the team to predict when work will be completed and ready for delivery with higher accuracy. - The Product Backlog is the single source of work that will be completed by the Scrum Team. - During **Sprint Planning**, the development team pulls items from the Product Backlog into a **Sprint Backlog** (a smaller subset of items that will be worked on during the current sprint). - The Product Backlog is continuously refined through a process called **Backlog Refinement** (or Grooming), where the team discusses, clarifies, and breaks down items into smaller, manageable tasks. 1. **User Stories**: A common format for functional requirements that describe what the user wants to achieve. 2. **Tasks**: Technical work that may not directly deliver user value but is necessary (e.g., setting up infrastructure). 3. **Bugs**: Issues that need to be fixed in the product. 4. **Features**: Larger pieces of functionality or capabilities that the product must support. 5. **Technical Debt**: Items that involve improving or refactoring existing code to improve performance or maintainability.