Agile 101 Course Recap

In software development, requirements for a feature or an app in a given service change often — whether driven by the business unit, unpredictable technical shifts, or customer feedback asking for a smoother experience that truly meets their needs. That’s just as important as the overall business goal. Deciding what to prioritize, and in what order, is the first step toward planning software development more effectively.

One principle everyone in software development should know is the Agile methodology — a process that gets everyone on a team seeing the work the same way, sharing the same goal, so the output satisfies the stakeholders involved.

The Agile 101 course was published on the pmd47 Digital Citizen Project website, taught by Agilist, an organization that trains Agile for leading companies and agencies nationwide.

Remember Scrum’s house with 3 numbers

3 : 5 : 3

The first 3 > 3 roles: Product Owner, Scrum Master, Developers

The Product Owner’s responsibilities

• Gather requirements from the business unit (in-house) or from customers, and decide what needs to be done
• Decide what to do first and what comes next (prioritize), aligned with the product vision
• Set acceptance criteria — once planning begins, what the expected output should look like, serving as the team’s definition of done
• Estimate the expected business value, whether in terms of ROI or user acquisition
• Coordinate with related teams — such as systems that need to be integrated, preparing test data, and conducting UAT (User Acceptance Testing) personally to verify before it reaches real users

The Scrum Master’s responsibilities

• Help the team follow the Scrum framework correctly and effectively
• Help the Dev team and PO communicate and align on requirements
• Help increase collaboration among stakeholders when needed

The Developers’ responsibilities

• Build and improve the software according to the definition of done set by the PO
• Write the development plan

The middle 5 > Scrum events

Each sprint consists of 5 events, as follows:

The last 3 > Scrum artifacts

Think of these as notes listing the items worked on in each sprint.

• Product backlog

  • A bucket of things not yet done, but planned for the future
  • These items are called product backlog items

• Sprint backlog

  • Items picked up and prioritized from the product backlog to work on in the upcoming sprint
  • Timelines for each item are framed during the sprint planning phase

• Product increment

  • The output of each sprint — it may be 100% complete or only partially done
  • Reviewed with stakeholders to gather feedback for the next sprint, hence the term “increment”

In real life, teams may not follow this Scrum guide to the letter, but it still gives teams useful ideas to apply within their own organizational context. In the end, adapting matters more than the theory. Really, the core principle of Scrum is that everyone on the Scrum team shares ownership of the product’s success — no hierarchy within the team, just communication that drives the work to completion.