Q1-Q5

0Q1. How you give estimation to your project? or new requirements?
Q2. What are the various Agile Ceremonies happen in your project?
Q3: Discuss the Azure DevOps Hierarchy structure?

================================================================================
Q1. How you give estimation to your project? or new requirements?

Answer:

1. Scope understanding. First I will make sure I have clear business and functional requirement.

2. Based on requirement I will draw my efforts required in 
  1. Front End, 
  2. efforts required in API changes or backend,
  3. Any infra changes
  4. NRF requirement changes like authentication etc
  5. Database changes
  6. Research etc.
3. I will include non coding work hours as well like
  1. Code review, UT, intergration tests,
  2. CICD pipeline adjustments.
  3. Environment setup, security, compaliance. etc.
4. I will put 15% risk buffer

5. I will discuss with team to make them feel confident and comfortable. 

------2nd answer below -------

1. Breaking into smaller tasksBreak the requirement further into smaller tasks and start estimating them. 
2. Past experience: Learning from your past. If you have already faced this type of requirements you might already have an idea how much time to allocate.
3. Expert Advice: New requirement might have an expert area of existing developer. Taking help in estimation could be a great benefit.
4. Considering all areas: Considering areas like writing UT cases, e2e test cases, fixing sonar issues, proper QA testing time, code review etc. 
5. Considering Optimistic and Pessimistic time variant: Try to calculate the max time implementation could take and min time implementation could take, based on that give average or the pessimistic time variant. 

=================================================================================
Q2. What are the various Agile Ceremonies happen in your project?

Answer:
In our Agile projects, we follow the standard Scrum ceremonies. These include:

Sprint Planning – At the start of each sprint, the team and Product Owner come together to decide what backlog items will be delivered. I usually help highlight technical risks, dependencies, and ensure the estimates are realistic.

Daily Stand-up – This is a short 15-minute sync where each member shares what they did yesterday, what they’ll do today, and any blockers. I attend to stay close to progress and step in quickly to remove technical or cross-team blockers.

Sprint Review (Demo) – At the end of the sprint, the team demonstrates the completed work to stakeholders. My role is often to ensure the technical aspects are represented well and that stakeholders’ feedback is captured for the next iterations.

Sprint Retrospective – After the review, the team reflects on what went well and what could be improved. I actively encourage my team to raise concerns around tools, environment, or processes and I take ownership of making improvements happen.

Backlog refinement (grooming) sessions, where upcoming items are discussed, clarified, and estimated. I contribute by giving technical inputs and ensuring architectural aspects are considered early.

=================================================================================
Q3: Discuss the Azure DevOps Hierarchy structure?

Answer:

Epic
 └── Feature (optional)
      └── User Story
           ├── Task / Sub-task
           └── Bug

Agile/Scrum Work Item Hierarchy (common industry usage)

  1. Epic

    • Large body of work, too big for a sprint.

    • Example: Implement User Authentication System.

    • Usually spans multiple sprints and is broken into stories/features.

  2. Feature (optional, often used in scaled frameworks or tools like Azure DevOps)

    • A grouping of stories that deliver a capability.

    • Example: Login and Registration capability.

  3. User Story

    • Smallest unit of customer value, written from the end-user perspective.

    • Follows the format: As a [role], I want [feature] so that [benefit].

    • Example: As a user, I want to reset my password so that I can recover my account.

  4. Task / Sub-task

    • Technical breakdown of how to implement a story.

    • Example: Create password reset API, Update UI form.

    • Tasks are typically owned by developers/testers inside the sprint.

  5. Bug / Defect

    • Represents an issue or error found either during development, testing, or production.

    • Bugs can be linked to a Story, Epic, or Sprint depending on process.


=================================================================================




=================================================================================



=================================================================================