SCRUM Project Management

Episode Breakdown

14:04 Theory

“Scrum’s early advocates were inspired by empirical inspect and adapt feedback loops to cope with complexity and risk.” ~ Michael James

Transparency is making all aspects of the process visible to those responsible for the outcome. It is defined by a common standard set by the team.

Inspection involves the team frequently reviewing the SCRUM process to detect variances but should not get in the way of working on the project.

Adaptation are the adjustments made to the process based on what is revealed through inspection.

Formal Events for Inspection and Adaptation

• Sprint Planning
• Daily SCRUM
• Sprint Review
• Sprint Restrospective

16:16 Values

SCRUM has five core values it is based on. These are Focus, Courage, Openness, Commitment, and Respect.

Focus on only a few things at a time working together to deliver valuable items quickly.

Courage to undertake greater challenges by working together as a team to provide support and resources to one another.

Openness to express what you are doing and address challenges and concerns as they appear.

Commitment to success comes from better control over ones own destiny.

Respect each member of the team as the team shares in successes and failures.

20:55 Roles

Product Owner

Creates and manages the product backlog by prioritizing the “wish list” of items. They do so by ordering the items to best acheive the goals of the project and ensuring transparency thoughout.

SCRUM Master

Functions as a servant leader for the team with no managerial power over the members of the development team. The SCRUM master serves the product owner by managing the backlog, helping the team to understand the backlog items, and ensuring the product owner does not micromanage the team. They serve the team by coaching for self-organization and cross-functionality of the members, removing impediments to progress, and facilitating the SCRUM events.

Development Team

The team is a small group of self organizing workers. Typical team sizes range from three to nine members serving in cross functional roles of programmer, business analyst, quality assurance, and design. There are no special titles or sub teams.

25:25 Backlog Breakdown

The product backlog is an ordered list of everything needed for the project including features, functions, requirements, and fixes. It is the singular source of requirements for the project ordered by importance with the higher order tasks having more details. Multiple teams may work on one product backlog.

The sprint backlog are the particular items from the product backlog that are under development for the current sprint. This contains all the requirements necessary to meet the sprint goals. New work that may be discovered in development or testing is added to the backlog by the team.

28:07 Sprint

“Time is divided into short work cadences, known as sprints, typically one week or two weeks long. The product is kept in a potentially shippable (properly integrated and tested) state at all times.” Michael James

The purpose of each sprint is a minimum viable product (MVP). This is presented to the product owner and the team at the end of the sprint. “Done” is defined by the product owner and th team.

Sprint goals are the objectives to be achieved by the sprint and provide guidance for the development team with flexibility on the implimentation. During the sprint no changes are allowed that risk the sprint goals.

In the planning of a sprint the team answers a the questions: What can be delivered in the sprint? and How will the work be achieved?

Sprints typically last one month or less, usually two weeks. This is based on what it takes to build the MVP. The sprint may be cancelled at any time by the product owner if the goals of the sprint fall outside of the scope of the project.

Each day the team meets for a 15 minute Daily SCRUM or Stand-Up. In this each member answers three questions:

• What have you worked on since the last stand-up?
• What are you working on next?
• What if anything is impeding your ability to meet the goals of the sprint?

After the sprint a Sprint Review is held with the team, product owner, and any key stakeholders. Here the product owner explains what has been “Done” and the team discusses what went well and what impediments they faced.

The final event for a sprint is the Sprint Retrospective. This occurs after the Sprint Review before starting the next sprint. In it the team meets without the product owner or any management to discuss an honest self evaluation of what worked well, what needs improvement, and what should not continue in the next sprint.