QA: Scrum Basics

A down and dirty outline of what's important in the world of scrum. Whereas AGILE is a project management that focuses on 'doing the right things right - and fast', SCRUM is a framework - or process - one can employ to drive results in an AGILE direction. Let's say  principle(AGILE) vs process(SCRUM)

  1. Transparency: Common Language/Definition of Done
  2. Inspection: Frequent analysis of progress
  3. Adapation: Constant adjustment to reality
    1. Sprint Planning Meeting
    2. Daily Scrum
    3. Sprint Review Meeting
    4. Sprint Retrospective (Post Mortem)

Scrum

Structured framework to bind together events, roles, and artifacts
Governs relationships and interactions between them

Scrum Team

  1. Product Owner
  2. Development Team
  3. Scrum Master

Product Owner

Maximize value of the product and work of Dev Team
Manages Product Backlog:

  1. Clearly expressing Product Backlog items;
  2. Ordering the items in the Product Backlog to best achieve goals and missions;
  3. Ensuring the value of the work the Development Team performs;
  4. Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what
  5. the Scrum Team will work on next; and,
  6. Ensuring the Development Team understands items in the Product Backlog to the level
  7. needed.

The Development Team

Do the work of each Sprint & Create the increment

  1. They are self-organizing. No one (not even the Scrum Master) tells the Development Team
  2. how to turn Product Backlog into Increments of potentially releasable functionality;
  3. Development Teams are cross-functional, with all of the skills as a team necessary to create
  4. a product Increment;
  5. Scrum recognizes no titles for Development Team members other than Developer,
  6. regardless of the work being performed by the person; there are no exceptions to this rule;
  7. Individual Development Team members may have specialized skills and areas of focus, but
  8. accountability belongs to the Development Team as a whole; and,
  9. Development Teams do not contain sub-teams dedicated to particular domains like testing
  10. or business analysis.

Scrum Master

Mentors Scrum process (Servant/Leader/Referee)

Scrum Master Service to the Product Owner

Scrum Master serves the Product Owner in several ways, including:

  1. Finding techniques for effective Product Backlog management;
  2. Clearly communicating vision, goals, and Product Backlog items to the Development Team;
  3. Teaching the Development Team to create clear and concise Product Backlog items;
  4. Understanding long-term product planning in an empirical environment;
  5. Understanding and practicing agility; and,
  6. Facilitating Scrum events as requested or needed.
  7.  

Scrum Master Service to the Development Team

The Scrum Master serves the Development Team in several ways, including:

  1. Coaching the Development Team in self-organization and cross-functionality;
  2. Teaching and leading the Development Team to create high-value products;
  3. Removing impediments to the Development Team’s progress;
  4. Facilitating Scrum events as requested or needed; and,
  5. Coaching the Development Team in organizational environments in which Scrum is not yet
  6. fully adopted and understood.

Scrum Master Service to the Organization

The Scrum Master serves the organization in several ways, including:

  1. Leading and coaching the organization in its Scrum adoption;
  2. Planning Scrum implementations within the organization;
  3. Helping employees and stakeholders understand and enact Scrum and empirical product
  4. development;
  5. Causing change that increases the productivity of the Scrum Team; and,
  6. Working with other Scrum Masters to increase the effectiveness of the application of Scrum
  7. in the organization.

Scrum Events

  1. Time-Boxed Events: Inspect and Add something
  2. The Sprint
  3. One month or less to reach “Done”

Back to back sprints

  1. Planning Meeting
  2. Daily Scrums
  3. Dev Work
  4. Review Meeting
  5. Sprint Retrospective

The Sprint

During the Sprint:

  1. No changes are made that would affect the Sprint Goal;
  2. Development Team composition and quality goals remain constant; and,
  3. Scope may be clarified and re-negotiated between the Product Owner and Development
  4. Team as more is learned.

Sprint Planning Meeting

  1. The work to be performed in the Sprint is planned at the Sprint Planning Meeting. This plan is created by the collaborative work of the entire Scrum Team.
  2. The Sprint Planning Meeting is time-boxed to eight hours for a one-month Sprint. For shorter Sprints, the event is proportionately shorter. For example, two-week Sprints have four-hour Sprint Planning Meetings.
  3. The Sprint Planning Meeting consists of two parts, each one being a time-box of one half of the Sprint Planning Meeting duration. The two parts of the Sprint Planning Meeting answer the following questions, respectively:

 

  1. What will be delivered in the Increment resulting from the upcoming Sprint?
  2. How will the work needed to deliver the Increment be achieved?
  1. Part One: What will be done this Sprint?
  2. Part Two: How will the chosen work get done?
  3. Sprint Goal: Milestone

Daily Scrum

  1. 15min Meeting
  2. Inspect/Forecast
    1. What has been accomplished since the last meeting?
    2. What will be done before the next meeting?
    3. What obstacles are in the way?

Sprint Review

The Sprint Review includes the following elements:

  1. The Product Owner identifies what has been “Done” and what has not been “Done”;
  2. The Development Team discusses what went well during the Sprint, what problems it ran
  3. into, and how those problems were solved;
  4. The Development Team demonstrates the work that it has “Done” and answers questions
  5. about the Increment;
  6. The Product Owner discusses the Product Backlog as it stands. He or she projects likely
  7. completion dates based on progress to date; and,
  8. The entire group collaborates on what to do next, so that the Sprint Review provides
  9. valuable input to subsequent Sprint Planning Meetings.

Retrospective

  1. Inspect how the last Sprint went with regards to people, relationships, process, and tools;
  2. Identify and order the major items that went well and potential improvements; and,
  3. Create a plan for implementing improvements to the way the Scrum Team

 

Scrum Artifacts

Product Backlog

The Product Backlog lists all changes to be made to the product in future releases:

  1. features
  2. functions
  3. requirements
  4. enhancements
  5. fixes

Product Backlog items have

  1. attributes of a description
  2. order
  3. estimate.

Ordered by

  1. value
  2. risk
  3. priority
  4. necessity

Monitoring Progress Toward a Goal

Sprint Backlog

  1. Product Backlog
  2. Plan for accomplishing it
  3. Getting to goal
  4. Accumulates as features/bugs identified

 

Monitoring Sprint Progress
Should be able to estimate total work remaining

Increment
The Increment is the sum of all the Product Backlog items completed during a Sprint and all
previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it
must be in useable condition and meet the Scrum Team’s Definition of “Done.” It must be in
useable condition regardless of whether the Product Owner decides to actually release it.

Definition of “Done”

This should be decided ahead of time, particularly for the QA team's sake as a company would drown in testing costs if there are realistic limitations placed on product quality, feature set, and time to market. The QA team should live every day trying to find the best value and efficiency in the testing effort. The 80%/20% rule - are a derivative thereof - applies and there's nothing wrong with creating a 'QA Backlog' so ideas that can't be accomplished immediately won't be lost when there's time to address. Traditionally, there is some 'woodshop' time between major relases or projects where one can - AND SHOULD - clean house, regroup and evaluate how things went, where they should go, and what's needed to get there. I call it a post-mortem and I find that groups should do this internally to maintain a high level of honesty, then push to the PM who in turn seeks cross-functional input. Calling a large meeting for a post-mortem usually does more harm than done as great ideas can be received as personal attacks and others never surface due to 'stage fright'. Be honest and its best to state ideas using positive language;

Coarse Verbiage:

Development Team always ends up moving slowly at the start of sprint, and then a crunch occurs.

Constructive Verbiage:

There should be meetings midday Tuesday to ensure problems that arise on Monday can be addressed and helped assigned before they impact project velocity.

Tags