Skip to content

Applied Scrum for Agile Project Management

Week 3 Scrum Team Formation

3.1.0 Prep for Scrum Team Formation

founding document: a charter.

  1. Project Objectives
  2. Project Stakeholders
    • all impacted people
  3. Project Constraints
    • standard, interface, etc.
  4. Project Risks
  5. Definition of Done
    • agree on how the work is closed.

As you go through this lesson think:

  • How many roles do you have in your project?
  • How are you organized? As individual teams? Do you have support teams?
  • Who defines work? What's the process?
  • Who has the final say to "accept" work? Are they on the team?
  • How might a Scrum team have advantages or disadvantages in achieving fast, innovative solutions?

Scrum Team Members

  • Product Owner (Variations)
    • Business Rep
    • Architect
    • Owner
  • Scrum Master (Variations)
    • Project manager
    • Junior PM
    • Business Analyst
  • Development Team Member (Variations)
    • Developer
    • Business Analyst
    • Tech Writer
    • Architect
    • Support

3.1.2 Scrum Team Formation Summary Points

The key document that sets up the team is the Charter. This includes:

  • Project Objectives - what the sponsors and/or customers expect from this project
  • Stakeholders - who "has a stake" from sponsors to customers and why. Includes technical, security, business, and operational stakeholders
  • Constraints - what must the project also do or do not in accomplishing the objective, such as standards, interfaces, and dependencies
  • Risks - what are major risks (internal and external), this includes business, technical, political, social, environmental
  • Definition of Done - the agreement among stakeholders of how work is closed by the Product Owner and supporting stakeholders Once the Team Charter is in-place, the team should assemble based on the skills needed to do the work:
    • Product Owner - person responsible for managing the Product Backlog; can only be one person;
    • Scrum Master - person responsible for facilitating and keeping the team on track; leads Sprint Planning and Retrospectives
    • Development Team Member - person on the team who takes responsibility for the team's success in completing the Sprint objectives

These are the general types of team members on a Scrum Team, however, we know that many times we need variations based on our organization. The following are typical variations

Product Owners variations

Types

  • Business Representative - from the business line using the product, or subject matter expert (SME) for customer
  • Technical Expert - from the systems engineering or technology group of the customer, has experience with building for business lines
  • Sponsor - the executive, director, or product manager for a business line (internal or external); focuses on marketing and feature analysis
  • Business Owner - the owner of the business selling the product; often a combination of other types of representatives Level of Availability
  • Dedicated - always on the team and available to the team; focusing on the backlog refinement whenever not supporting other team members
  • On-Call - available when needed at all times; however, may have limited time outside of team support for backlog refinement (e.g. other duties)
  • Matrixed - works on multiple products or projects, balancing time based on their own direction or the direction of departmental goals
  • Minimal - available only for Sprint ceremonies and minimal other times
  • Absent - available with long lead times for set consultation hours; cannot predict if/when they will be avialable Scrum Master variations

Types of facilitation

  • Facilitator - facilitates planning meetings, daily scrums, coordination with stakeholders (requirements, etc.), and retrospectives
  • Project Manager - works as facilitator, as well as managing human resources; and is responsible for reporting and project success
  • Junior Project Manager - works as facilitator and is responsible for reporting and project success for the Scrum team
  • Business Analyst - works as facilitator and also provides supports for Product Owner and Development Team with requirements elaboration

Types of Availability * Dedicated - soles works on the Scrum team * Split - works across multiple Scrum teams (can be the same or different projects or product lines) * Rotating Team Member - can be a rotating member of the Development Team who acts as the Scrum Master for a Sprint * Matrixed - can be part of a department with responsibilities to the department, Program, Program Management Office, etc. * Minimal / Absent - can be only available for running ceremonies and on-call for other facilitation

Development Team Member variations

Types of representation

  • Generalizing Specialist - a team member that can perform any role as needed, but is trained in a certain skill set (usually development)
  • Developer (Hard/Software) - a technical team member who focuses primarily on building the product to specifications
  • Business Analyst / Tester - an analyst who defines and checks the work being developed by the team meets the Product Owner's intent
  • Technical Writer - an analyst who provides support for other team members in capturing notes, metadata, and communicating work
  • Architect - an experienced team member in a technical or business domains that serves as subject matter expert (SME)
  • Support Team - a team member that provides enabling technology, such as work tracking software, builds, deployments, machining, etc.

Types of Availability

  • Dedicated - soles works on the Scrum team
  • Split - works across multiple Scrum teams (can be the same or different projects or product lines)
  • Matrixed - can be part of a department with responsibilities to the department, other projects or product lines, or Centers of Excellence
  • On-Call - is available as needed, when needed by the team to provide surge support or expert guidance
  • Absent - available with long lead times for set consultation hours; cannot predict if/when they will be available

There are many advantages to having fully dedicated team members. Most often the objections for fully dedicating team members arise when considering the Product Owner and the Scrum Master. It appears as if these team members have a lot of "downtime" during the actual Spring Execution phase. This is hardly the case:

  • Product Owners need to use time between ceremonies to liaison with Stakeholders
  • Product Owners need to research market changes (Political, Environmental, Social, Technological) to validate product features
  • Product Owners need to work with team members and provide quick feedback to keep the Development Team running as fast as possible
  • Scrum Masters should to facilitate meetings, especially with stakeholders - this can take a long time to research and prepare!
  • Scrum Masters should to help guide requirements, development, and testing based on best practices
  • Scrum Masters should to help escalate issues outside the team; and address real-world obstacles that get in the team's way
  • Scrum Masters should always be analyzing the data of the team's performance to identify continuous improvement opportunities
  • Scrum Master is often having to "prep" the stakeholders and retrain where necessary the Product Owner and Development Team

How does this compare with your organization? Do you have "professional facilitators" who can ensure productive meetings? What about dedicated product owners to answer questions and make calls so development keeps on-track?

3.1.4 Scrum Team Formation References

Scrum Alliance - www.scrumalliance.org

Note that the real-world modifications and adjustments are based on the real-world experiences of the Instructor, Team, and their colleagues who all deserve credit for the production of this material.

3.2.0 Prep for Three Part User Story

In this next lesson you'll be taken through the process of writing a good User Story, and it's three parts:

  • Value Statement
  • Assumptions
  • Acceptance Criteria

These elements are essential for any story because often what is captured is only one or two parts at most.

The Value Statement guides development with a simple formula:

As a ...[Who]...
I want... [What Functionality]...
in order to... [Why It's Important].

This framework is easy enough to read and learn, but hard to master. Using this framework enables inquiry-based elaboration by the team (asking good questions), and offers a means of empathizing with the user [Who] may not be able to fully communicate their needs.

The Assumptions constrain the development based on additional considerations for the specific User Story, Theme, or Product. This is also the portion of the User Story that captures any non-functional requirements for implementation. By having a well specified set of assumptions the Development Team knows the bounds of the solution space.

The Acceptance Criteria set the goal for the product component being built by stating what tests must be passed. These tests are logical and/or numerical in nature for clearly achievable goals of the user story. Often through elaborating Acceptance Criteria the Development Team can better assess the true needs and assumptions for implementing a given story.

Critical thinking point - think about how your requirements are currently captured. Are they one line? A hiearchy of detailing constraints? How do you know the priority, reasoning, and means of validating your requirements are met?

3.2.2 Three-Part User Story Summary Points

There are three parts to a User Story:

  • Value Statement
  • Assumptions
  • Acceptance Criteria

These work together to for the complete "User Story." It is NOT just the Value Statement.

The proper means of creating a Value Statement is up for debate, but usually the statements are as follows:

As a...[Who]...I want to...[What Functionality Desired]...in order to...[Why It's Important].

The "Who" is the user, either directly using or consuming outputs from the product the Development Team is building. It's important that if this user is not clearly defined already in the Project Charter then they are added by the Product Owner, with consensus by the Stakeholders. This ensures there's a clear understanding when say the term "End User" is put into the [Who] part of the Value Statement. Usually "End User" is too vague. It should be a descriptive title such as "Research Librarian" or "Fighter Co-Pilot."

The "What" should be the MOST important aspect of the component being built. Often because product features serve multiple users and needs or wants of users the User Stories can seem to compete with one another. When multiple types of value or outputs are created by a new product feature or component, make sure that the one that is put in the Value Statement is the priority. Priorities matter because a product that does everything for everyone in the end serves no one well.

Most importantly the "What" or "Functionality Desired" should be stated in only business terms. Examples:

I want to Login Using My User Name and Password --- WRONG!
I want to access my account --- RIGHT!

The "Why It's Important" is a critical failing of most User Stories. This is true for experienced and beginning Scrum teams. The easiest trap is to simply restate the "What" in another way. Such as "I want to Login to access my account." As stated above, the proper "What" in this statement is "access my account." So what's the "Why?" It could be:

  • To check notifications
  • To assign work
  • To check the rankings of my fantasy football team

The key is that it's important and the MOST important "Why" of the feature or function. Others that are less important belong in the Assumptions.

Additional key points:

  • Assumptions are a bucket for everything else
  • Captures less important value created by the User Story
  • Captures detailing of Why the user story is important
  • Identifies constraints from preceding or proceeding tasks, work, components, etc.
  • Identifies all the standards, influences, reference architectures, etc.
  • Captures other reasons "Why" this story might be important
  • Can limit the Acceptance Criteria and the Value Statement - not just the Value Statement

The only information that is not needed to be listed here, are standard procedures captured in the Definition of Done.

  • Acceptance Criteria are NOT restatements of the Value Statement
  • Should clearly define the primary use cases for testing
  • Must specify any performance or loading that the product increment should meet
  • Must be comprehensive in detailing all tests that will be run to close the story
  • Finally it's important to note that all User Stories should be modular because they capture business functionality. If written correctly these shouldn't ever be in conflict because of technical dependencies.

User Stories are owned by the Product Owner when in the Product Backlog, and then once they are moved into the Sprint Backlog they are owned by the Development Team. The Development Team can update these stories with comments, but cannot change the Value Statement, Assumption, or Acceptance Criteria without the Product Owner and Development Team Members' consent.

All User Stories are governed by the Project's Definition of Done. In this way the Definition of Done is the hidden "Fourth Part" of any user story, although it is focused on process for closing a story. The Definition of Done captures all the standard requirements for completing work defined in a User Story, such as:

  • Standard approvals,
  • Reviews by stakeholders
  • Prototyping (if required)
  • Documentation (for sustainability, reporting, etc.)
  • Design constraints (for compliance, integration, etc.)

In this way the Definition of Done helps to modularize the statements within an User Story; but it also provides a clear set of expectations around quality control and sustainability. These benefits are further elaborated in part in this course, and in greater depth throughout the Agile Project Management Certificate program.

3.2.4 Three-Part User Story References

Credit for clearly developing an understanding of User Stories belongs to IBM's Agile Center of Excellence, and in particular Paul Gorans of IBM.

His lessons derive from his work developing the Agile With Discipline (AWD) framework made famous by Scott Ambler as an open-source publication called Disciplined Agile Delivery (DAD).

Additional Resources for great User Story Development Include: