Agile Scrum Basics

Agile Manifesto was codified in 2001 in Snowbird by Scrum, XP, and DSDM practitioners. Agile Manifesto includes:

Individuals and Interactions OVER processes and tools
Working software (systems) OVER comprehensive documentation
Customer collaboration OVER contract negotiation
Responding to change OVER following a plan

These values are at the core of why agile works and continues to be used on projects with high uncertainty today.

Sprint Basics

Sprint basics include the three parts of a Sprint:

  • Sprint Planning
  • Sprint Development
  • Sprint Retro & Review

What is Sprint?

A Sprint is a timebox, or a period that is used to contain the time allowed for work to be completed. It can be anywhere from two weeks to a month (although shorter is becoming more popular among advanced practitioners).

Sprint Planning

Sprint Planning starts with the Product Owner selecting the work to be done from the Product’s Backlog. The Product Backlog is the list of work that is prioritized by its importance, either for ongoing improvement or the completion of a new product. The Team reviews the stories and then selects what work they will be able to complete during the sprint. This process is facilitated by the Scrum Master who does not participate in the doing of work, but instead is focuses on enabling the team to move quickly with good processes and best practices. The final set of stories should form a cohesive “product increment” that the team can demonstrate by the end of the sprint.

Input: Product Backlog of stories prioritized by the Product Owner
Process: Review and select stories for the sprint
Output: Sprint Backlog of stories the team commits to complete by the end of the Sprint

Sprint Execution

Sprint Development begins with the daily standup. Daily standups are self-reporting of the team on what work they will get done that day. This is usually done around a Kanban board, or other big visual information radiator (BVIR). The team opens only a few stories at a time and work story-by-story to analyze, build, and test the work. The result by the end of the Sprint is a shippable increment that can be demonstrated to the product owner. Meetings are facilitated by the Scrum Master, and the Product Owner determines if a Story is complete to meet the stakeholder needs.

Input: Sprint Backlog of stories the team commits to complete by the end of the Sprint

Process: Daily reporting and execution against a few stories at a time: designing, building, testing and closing

Output: A shippable product increment that can be demonstrated

Sprint Review and Retrospection

Sprint Retro and Review are ceremonies to gain feedback and drive continuous improvement into the team.

Sprint Review is the event where the Product Owner demonstrates the product increment from the Sprint to Stakeholders. This is an opportunity to gain stakeholder buy-in and feedback, so the team knows its on track with the product direction. The Product Owner can also get feedback on what should be in the next Sprint.

The Sprint Retrospective or “Retro” is the second ceremony used to close a sprint. The Retro involves the team going into a room to evaluate how the sprint went, and identify opportunities for improvement in the next sprint. The best Sprint Retros are run as games to facilitate input from the whole team and quickly identify improvements.

Input: Shippable product increment that can be demonstrated

Process: Demonstrations and games to facilitate feedback on the product and team processes

Output: Feedback on the product’s direction and actions to improve the next sprint

Agile Change Management

Remember that in Agile we vary scope to target just what the customer needs, so we don’t waste time or money in the process. That’s the power of varying scope. It’s fast and limits waste by reducing the work to a minimum viable product (MVP) that meets the project objectives (in the charter).

To do this, Every Agile project needs:

  • Shared Vision Robust to Change (can vary scope and stay on target)
  • Whole Teams (customer + cross-functional team)
  • Incremental Delivery (learn by doing and using small “sprints”)
  • Continuous Integration & Testing (teams test increments to ensure they work)

Scrum, SAFe, or Disciplined Agile are all frameworks that help define roles and processes to scale and implement the methodology of Agile. They provide a shared language. But the method remains the same.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.