How to Scrum and be Agile? How to form scrum team? How to write user story?

 

All projects begin with the same founding document: a charter. Charters are essential to setting the direction and project objectives that will guide the team to completion. They should also include key information needed to manage the work:

• Project Objectives
• Project Stakeholders
• Project Constraints
• Project Risks
• Definition of Done

If you're managed a project before this should look familiar, except perhaps for the Definition of Done. This is a critical additional element added by the Agile framework that defines how work will be closed incrementally throughout the project.

Having a Charter allows for the correct formation of  team. You know what the work is, what it is not, who cares, the risks in performing the work, and the way you'll finish the work. All aspects are clear to select the appropriate team members based on these parameters.

In "pure" Scrum is very basic with only three roles: Product Owner, Development Team Member, and Scrum Master. In reality teams often form as many derivatives of these roles.

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?

Consider the difference an approach like this might make, and the challenges in implementing it.

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.