The document discusses epics, user stories, and bug reporting in agile project management. It defines epics as large bodies of work that require multiple sprints to complete and encompass multiple user stories. User stories are written from the user perspective to capture requirements. Bug reports document issues to aid resolution. Epics are broken into user stories and tasks which are estimated and tracked to facilitate incremental delivery.

1. Epic, Story and Bug Reporting

2. Introduction to Epic
• An epic is a substantial body of work that is too large to be
completed within a single sprint or iteration.
• It is larger in scope than a user story and typically encompasses
multiple user stories or work items.
• Epics help to organize and prioritize work, facilitate collaboration
among teams, and provide a big picture view of project progress.

3. Characteristics of Epic
• Size and Scope: Epics are larger in size and broader in scope
compared to user stories or tasks. They require multiple iterations
to complete.
• Cross-Functional Nature: Epics often involve multiple teams or
disciplines, requiring collaboration across different areas of
expertise.
• Strategic Importance: Epics align with strategic goals and
objectives of the project or product. They address critical user
needs or deliver significant business value.

4. Purpose of Epics
• Organization and Prioritization: Epics help organize and categorize
work, enabling teams to prioritize based on business value,
dependencies, and project goals.
• Flexibility and Adaptability: Epics provide flexibility to adapt and
refine requirements as the project progresses, allowing for
changes in scope or priorities.
• Incremental Delivery: By breaking down epics into smaller user
stories or tasks, teams can deliver incremental value to
stakeholders throughout the project.

5. Epic management and tracking
• Product Backlog: Epics are typically added to the product backlog,
where they are prioritized based on business value and
dependencies.
• Sprint Planning: During sprint planning, teams select user stories
or tasks from the product backlog to work on during the sprint,
including those related to epics.
• Progress Tracking: Regularly track the progress of epics and their
associated user stories, ensuring visibility and identifying any
potential risks or issues.

6. Managing Epics
• Epics are managed and tracked throughout the project lifecycle
using a product backlog.
• Epics are prioritized based on business value, dependencies, and
project goals.
• Techniques like user story mapping and collaborative workshops
help break down epics into smaller user stories or tasks.
• Regular progress tracking ensures visibility and identification of
any risks or issues associated with epics.

7. Breaking down Epics
Breaking down epics into user stories is a key step in Agile project
management to make large-scale work more manageable and
actionable.
Definition of User Stories:
• User stories are concise, customer-centric descriptions of a
specific feature, functionality, or user requirement.
• They are typically written from the perspective of the end user or
customer and focus on the value delivered.

8. Purpose of breaking down Epics
• Manageability: Breaking down epics into user stories allows teams
to work on smaller, more manageable units of work within a
sprint.
• Incremental Delivery: User stories enable incremental delivery of
value to stakeholders throughout the project, as each user story
represents a distinct deliverable.
• Collaboration and Understanding: Breaking down epics into user
stories promotes better communication and understanding among
team members, stakeholders, and customers.

9. How to Write an Epic?
• Step 1: Name the epic.
• Step 2: Write a narrative explaining the epic.
• Step 3: Establish the scope for the epic.
• Step 4: Define completion for the epic.
• Step 5: Break the epic down into stories.

10. Epic format
Source: aha.io

11. Introduction to Story
• In today's competitive landscape, creating customer-centric
solutions is more important than ever.
• Stories offer a powerful approach to capturing and addressing
customer requirements effectively.

12. What is Story?
• Stories are concise, customer-focused descriptions of a desired
functionality or feature from the user's perspective.
• They are a fundamental part of agile development methodologies,
such as Scrum or Kanban.
• Stories promote collaboration and serve as a shared language
between stakeholders, product owners, and development teams.
• With their customer-centric approach, stories foster a deep
understanding of user requirements and contribute to building
solutions that truly address their needs.

13. Story Format
• The structure of a story is typically represented using the "As a
[user], I want [action], so that [benefit]" template.
• This format provides a concise and consistent way to capture the
user's role, the desired action or functionality, and the benefit or
value it brings.

14. Story Format
Examples:
• As a customer, I want to be able to track my order online so that I
can stay updated on its progress.
• As a manager, I want to generate monthly reports automatically so
that I can analyze the team's performance efficiently.
• As a student, I want to access learning materials on my mobile
device so that I can study on the go.

15. Story Format
Source: aha.io

16. User Persona
• User personas are fictional representations of target users or
customer segments that capture their characteristics, behaviors,
and goals.
• User personas play a crucial role in creating stories that align with
user’s needs and expectations.
• By understanding the motivations, preferences, and goals of
different user personas, development teams can create more
relevant and valuable solutions.
• They help uncover insights into user behavior, pain points, and
desires, guiding the creation of user stories that resonate with the
intended audience.

17. Story Mapping
• Story mapping is a collaborative technique that helps teams
visualize the user journey and prioritize features or functionalities.
• Story mapping allows teams to understand the user's experience
from start to finish and identify the necessary steps to achieve
their goals.
• It helps in identifying dependencies, gaps, or missing features,
enabling teams to plan and prioritize effectively.
• By organizing user stories horizontally along the user's journey and
vertically by priority, teams can create a roadmap for
development.

18. Story Mapping
Source: batimes.com

19. Acceptance Criteria
• Well-defined acceptance criteria are crucial for ensuring that
stories are completed successfully and meet the intended
outcomes.
• Acceptance criteria outline the specific conditions or requirements
that must be met for a user story to be considered complete and
approved.
• They provide clarity and shared understanding between the
development team and stakeholders, minimizing ambiguity and
misinterpretation.

20. Acceptance Criteria
Source: Intellisoft.io

22. Estimation
• Estimating user stories is an important aspect of agile
development to plan and allocate resources effectively.
• Different approaches can be used for estimation, such as story
points or relative sizing.
• Story points are a relative measure of effort, complexity, or size
assigned to user stories based on their relative comparison to
each other.
• Relative sizing compares user stories against a reference story to
determine their relative effort or complexity.

23. Tasks and Sub tasks
• Task: Represents work that needs to be done.
• Sub-Task: A smaller piece of work required to complete a task.
Importance of Sub-Tasking:
• Not all stories or tasks need to be sub-tasked.
• Sub-tasking is optional and should be decided by the team.
• If a story or task is sub-tasked:
– All sub-tasks must be completed.
– Completion of all sub-tasks leads to the story or task being
considered complete.

24. Types of Sub Tasks
a. Dependent Sub-Task:
• A sub-task that relies on the completion of another task.
• Example: Before designing a website, content creation must be
completed.
b. Sequential Sub-Task:
• A sub-task that follows a specific order or sequence.
• Example: To build a house, foundation construction comes before
erecting walls.

25. Types of Sub Tasks
c. Parallel Sub-Task:
• Sub-tasks that can be worked on simultaneously.
• Example: In a software development project, front-end and back-
end development can happen concurrently.
d. Optional Sub-Task:
• A sub-task that is not essential for the completion of the main
task.
• Example: Adding animations to a website can be an optional sub-
task.

26. Benefits of Sub-tasking
• Provides a granular breakdown of work.
• Facilitates better task management and tracking.
• Enables parallelization of work.
• Enhances clarity and understanding of task dependencies.

27. Dev Task and Sub-Tasks
• Dev Task:
– Represents a development task that needs to be completed.
• Sub-Tasks:
a. Review Story:
– Evaluate the user story or task requirements.
– Understand the scope and objectives of the task.
b. Estimate the Story:
– Assess the effort required to complete the task.
– Provide an estimation of time, resources, and complexity.

28. Dev Task and Sub-Tasks
c. Designing:
• Plan and create the overall structure and architecture.
• Determine the components, modules, or UI/UX elements.
d. Coding:
• Write code to implement the desired functionality.
• Follow coding standards and best practices.

29. Dev Task and Sub-Tasks
e. Unit Testing:
• Test individual units or components of the code.
• Verify the correctness of the implemented functionality.
f. Integration Testing:
• Test the integration of multiple components or modules.
• Ensure proper interaction and functionality across the system.

30. QA Task and Sub-Tasks
• QA Task:
– Represents a quality assurance task that needs to be
completed.
• Sub-Tasks:
a. Review Test Story:
– Evaluate the test story or task requirements.
– Understand the scope and objectives of the testing.
b. Prepare Test Cases:
– Identify specific test scenarios to be executed.
– Define inputs, expected outputs, and test steps.

31. QA Task and Sub-Tasks
c. Prepare Test Scenarios:
• Create different scenarios to cover various use cases.
• Consider different paths and conditions for testing.
d. Prepare Test Data:
• Gather or generate necessary data for testing.
• Ensure test data covers different scenarios and edge cases.

32. Bug Tracking
• Also known as issue tracking or defect tracking, is the process of
identifying, documenting, and monitoring software defects or
issues throughout the development lifecycle.
• It involves keeping a record of reported bugs, tracking their status,
and ensuring that they are resolved.

33. Importance of Bug Tracking
• Issue Identification: Bug tracking helps identify and document
software defects, providing details for problem understanding and
resolution.
• Issue Prioritization: Bugs are prioritized based on impact and
severity, ensuring critical issues are addressed first.
• Collaboration and Communication: Bug tracking facilitates
teamwork and reduces miscommunication by providing a
centralized platform for sharing updates, assigning responsibilities,
and tracking progress.

34. Importance of Bug Tracking
• Workflow Management: Built-in workflows streamline bug
resolution, ensuring proper addressing, review, and verification.
• Historical Data and Analysis: Bug tracking systems maintain a
record of issues, enabling trend analysis, identifying recurring
problems, and improving software quality.
• Customer Satisfaction: Prompt bug tracking and resolution
enhance customer satisfaction, demonstrating commitment to
quality and responsiveness.

35. Bug Report & Bug Reporting
• A bug report is a document that communicates and documents a
software issue or defect.
• It serves as a means of reporting problems encountered in the
software and provides crucial information for developers and
testers to understand and address the issue effectively.
• A well-structured bug report is essential for the smooth
functioning of the bug tracking process and the overall software
development lifecycle.
• The series of activities related to writing a effective bug report is
bug reporting.

36. Bug Report Components
• Defect ID: A unique identification number assigned to each bug or
defect. It helps in tracking and referencing the specific issue
throughout the software development lifecycle.
• Defect Description: A detailed description of the bug or defect,
including information about the module or area of the software
where the defect was found.
• Version: The version number of the application or software in
which the defect was found. This information helps developers
identify if the issue has already been addressed in subsequent
versions or if it is specific to a particular release.

37. Bug Report Components
• Steps: Detailed steps or procedures, along with screenshots if
applicable, that can help developers reproduce the defect.
Providing clear and precise instructions helps ensure that
developers can recreate the issue accurately and investigate the
root cause effectively.
• Date Raised: The date when the defect was reported or raised.
This information helps in tracking the timeline of bug reports and
evaluating response times.

38. Bug Report Components
• Reference: References to relevant documents or resources that
can aid in understanding the bug or defect. This may include links
to requirements documents, design specifications, architecture
diagrams, or even screenshots of error messages.
• Detected By: The name or ID of the tester who discovered and
reported the defect. This helps in identifying the individual
responsible for raising the issue and facilitates further
communication or clarification if needed.

39. Bug Report Components
• Status: The status of the defect indicates its current state in the
bug tracking system. It could be Open, In Progress, Resolved, or
Closed, among others.
• Fixed by: This field captures the name or ID of the developer who
addressed and resolved the defect. It helps track accountability
and facilitates further communication or collaboration if needed.

40. Bug Report Components
• Date Closed: The date when the defect is officially closed signifies
the point at which it has been addressed and considered resolved.
It helps in tracking the timeline .
• Severity: Severity reflects the degree of impact the defect has on
the application or system. It assesses the criticality of the bug,
ranging from low to high severity. A high severity defect indicates
a significant impact on functionality, security, or user experience,
while a low severity defect represents less critical issues.

41. Bug Report Components
• Priority: Priority defines the degree of urgency in fixing the defect.
It indicates the order in which defects should be addressed based
on their impact and urgency.
Generally, high severity defects are assigned higher priority to ensure
they are resolved quickly, while low severity defects may have lower
priority and can be addressed at a later stage.

43. Writing an Effective Bug Report
• Be clear and concise in the description.
• Include all necessary details for developers and testers to
understand and reproduce the issue.
• Use a professional and respectful tone.
• Provide relevant attachments or additional resources.

44. Bug Report Types
• Coding Error: This type of bug report pertains to issues caused by
errors or mistakes in the code implementation. It may include
syntax errors, logical flaws, or incorrect algorithmic
implementation
• Design Error: Design error bug reports address problems that
stem from flaws or shortcomings in the software's overall design
or architecture. These issues may result in inefficient performance,
scalability limitations, or difficulties in maintaining or extending
the software.

45. Bug Report Types
• New Suggestion: A new suggestion report captures ideas or
recommendations for improving the software. This type of report
suggests enhancements, new features, or changes that could
enhance the user experience or functionality of the software.
• Documentation Issue: Documentation issue bug reports focus on
problems related to the software's documentation, such as user
manuals, help files, or API references.

46. Bug Report Types
• Hardware Problem: Hardware problem bug reports address issues
that arise from the interaction between the software and the
underlying hardware components.
These issues may involve compatibility problems, driver conflicts, or
other issues specific to the hardware environment in which the
software operates.

47. Bug/Defect Lifecycle

48. Bug Tracking Tools
● JIRA
● BugZilla
● Mantis
● Monday
● Clickup
● Zoho Bug Tracker
● Asana
● Redmine