These are just notes I took reading various Scrum documents. I tried to write down every concrete action that someone can take as part of a Scrum process.
Going in:
- Company Vision Statement
- Market Analysis
Create Stakeholder Selection Criteria: customers (acquires the product), users (use it), and sponsors (provides resources to support items)
Identify Scrum Master using Selection Criteria
- available and can fully commit to the project
- good problem solving skills
- servant leadership style
Identify Stakeholders using Selection Criteria
Scrum Guidance Body formalizes organizational practices related to Scrum:
- government regulations
- security
- organization-specific
Review Project Business Case
- could be formal or informal
- background
- business purpose
- desired outcomes
SWOT analysis: strengths, weaknesses, opportunities, and threats
Gap analysis:
- gap in market segmentation
- gap in profit expectations and realization
- narrow in on key variables affecting gap
- strategy for closing gap: customer-focused, operations-focused, or product-focused
High level business requirements are organized into Program Backlog Items
Identify Product Owner
Project Vision Statement
- business outcomes that the project is expected to fulfill
- its fulfillment helps fulfill the organization's mission statement
- serves as inspiration
- provides focus
- not too specific, allow flexibility
- reference problem, not solution
Create Scrum Master selection criteria
User Group Meetings may be held to discuss appropriate Epics
STAKEHOLDER MEETINGS
Find out what business value is expected by the customer
Product Owner obtains approval of the Project Vision Statement from the key decision-makers in the organization (executives and/or some form of a project or program management board)
business case is presented to the stakeholders and sponsors
Perform a proper business assessment
Review the Project Business Case
What is the project reasoning?
- inadequate capacity to meet existing and forecasted demand
- decrease in customer satisfaction
- low profit
- legal requirement
measurable improvements in a product, service, or result which could be provided through successful completion of a project
Opportunity cost covers the next best business option or project that was discarded in favor of the current project
Identify risks: uncertain or unplanned events that may affect the viability and potential success of the project.
- review lessons learned
- risk checklists from Scrum Guidance Body
- risk prompt lists from Scrum Guidance Body
Estimate risk:
- probability (very likely, could happen, probably won't, extremely unlikely)
- proximity (when it's likely)
- impact (effect on business/cost)
- expected monetary value
Add risks to Prioritized Program Backlog
Identify actions teams can take to mitigate risk
- plan B/fallback may be formulated
Potential events are represented in a tree with a branch extended for each possible outcome of a risk event
length or duration of a project and the time over which its benefits will be realized.
Project costs are investment and other development costs for a project.
ROI = (expected cost - expected revenue) / (expected cost * time until realization)
Customers prioritize stories and requirements: “Must have,” “Should have,” “Could have,” and “Won’t have”.
Prioritize stories: Delighers/Satisifiers/Dissatisfiers/Indifferent
Draw line of Minimum Marketable Features
Project Vision Statement is baselined
Issues are generally well-defined certainties that are currently happening
Check risk attitude:
- risk averse: don't take risks
- risk neutral: whatever has the best ROI
- risk seeking: take all the risks
Create Program Backlog Items
(Design, basically)
- In the initial stages of writing, most User Stories are high-level functionalities. These User Stories are known as Epic(s). Epic(s) are usually too large for teams to complete in a single Sprint.
- generates Change Requests
Prioritize requirements based on business value delivered to customers and users
USER MEETINGS
Users provide Scrum Core Team with firsthand information, expectations
- Leads to change request for Acceptance Criteria
- Helps develop epics
USER STORY WORKSHOPS
Scrum Core Team invited, and at times other Stakeholders
Prioritize Requirements
Scrum Code Team has shared perspective on Acceptance Criteria
Epics and User Stories
- are from users POV
- are easy to understand
- can be reliably estimated
Understand user expectations for the deliverables
Teambuilding
Delve into product details
USER INTERVIEWS
Give opinions and ratings
Come up with ideas/suggestions
Solve Problems
User/Customer Interviews
Reach Consensus
QUESTIONNAIRES
Developing strategy to deal with the risks
Customers and users define the prioritized list of requirements and User Stories in the Prioritized Product Backlog
MoSCoW prioritization
Pairwise comparison
100-point method
Waiting for three Development Team members, for optimal interaction and productivity gains
People join Development Team
- Only team members who will be available and can fully commit to the project should be selected
- trade off experience versus salary
Train Scrum Team members on Scrum practice Scrum Master helps Product Owner arrange the Product Backlog to maximize value
Scrum Master removes impediments to the Development Team’s progress
Development Team becomes full, nine members joined
Business or project requirements written in the form of a User Story is added to backlog
Product Owner (with possible assistance of Development Team Member) orders the items in the Product Backlog to best achieve goals and missions
Product Backlog makes itself visible to all:
User stories have
- story
- time estimates
- acceptance criteria
- status of acceptance/done criteria
- value
- risk
- dependencies
- approved revisions
Affinity Estimation
Planning Poker
Address risks that can potentially decrease value
Assess the viability and achievability of a project
Demonstrating prototypes to customers and simulating their functionalities to confirm value
Communicate risks to stakeholders
- impact
- plans for response/mitigation
Grooming is done WELL IN ADVANCE of Spring Planning Meeting #scrum-master-eval
Risk-based spike: two to three day exercise, experiment to understand risk through research or prototype (before Epics created)
- good for new technologies/tools
- good for long user stories
- can help for estimating time
Trial project/Proof of concept
- illuminate technical viability
- hone in financial viability
- predict time and cost
- reduce or quantify risks
- predict possible effects of the actual project
- demonstrates and verifies ideas behind project
- may be a prototype
- help understand requirements
- assist in critical design decisions
- needn't represent deliverables
Scrum Master oversees
Scrum Core Team reviews the User Stories in the Prioritized Product Backlog to develop a Release Planning Schedule
Sprint is timeboxed under a month
- Arbitrary Time-boxing can lead to de-motivation of the team
- If project requirements are generally stable and major changes are not expected in the near future, the Length of a Sprint may be set to be longer, 4 to 6 weeks.
- if project requirements are not very well defined or if significant changes are expected in the immediate future, the Length of Sprint may be relatively shorter, 1 to 3 weeks
- take into account planned release dates
- time to get work done
- length of sprint should be consistent (causes reset on project-level tracking, velocities become useless)
Product Owner manages stakeholders' expectations
Product owner helps sponsor understand financial bottom line related to a product
Product Owner decides minimum marketable release content
Sprint gets a goal of what is to be built
Sprint gets a design
Product Backlog shows what the Scrum Team will work on next
Product Owner responsible for everyone's understanding of
- items in the Product Backlog
- business justification and the value the project is supposed to deliver
Scrum Master asks Team Member for more clear and concise Product Backlog items
Product Owner writes user stories which
- depict customer’s requirements
- include User Story Acceptance Criteria
Product Owner calls Story Writing Exercise
- Scrum Team Members create User Stories
Backlog gets Change Requests
Scrum Master and Scrum Team estimate the effort required to develop the functionality described in User Story
Estimate User Stories
Identify Tasks
- risks in backlog get mitigated
Estimate Tasks
Product Owner works with the stakeholders to understand which business requirements provide maximum business value
Evaluate stories based on...
- Value
- Risk or uncertainty
- Dependencies
Create Sprint Backlog
Scrum Guidance Body interacts with Scrum Team members during the Create User Stories, Estimate Tasks, Create Deliverables, and Groom Prioritized Product Backlog processes to offer guidance and also provide expertise as required.
Sprint Planning is timeboxed under 8 hours
Product Owner discusses the objective that the Sprint should achieve / explains the highest priority User Stories or requirements
Product Owner (with possible assistance of Development Team Member) clearly expresses Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal
high priority User Stories are considered for inclusion in the Sprint
Scrum Team self-organizes and aims to create the Sprint Deliverables (Product Increment) from the User Stories in the Sprint Backlog
Scrum Team unanimously commits to User Stories ( == Sprint Goal)
Scrum Team brakes down committed User Stories into a Task List
Scrum Team estimates the effort required to accomplish each task in the Task List
Scrum Team organizes tasks into Sprint Backlog
Sprint is locked and Product Owner cannot change Acceptance Criteria for a User Story
all requirements related to an ongoing Sprint are frozen during the Sprint
Each Scrum Team Member shares:
- What have I done since the last meeting?
- What do I plan to do before the next meeting?
- What impediments or obstacles (if any) am I currently facing?
Scrum Team may discuss risks related to their Tasks
Scrum Master manages risks, changes, and impediments
Scrum Team identifies risks which have appeared
Scrum Team identifies risks which have become issues
Product Owner keeps the business justification in the Project Vision Statement updated with relevant project information to enable the key decision makers to continue making informed decisions
Scrumboard tracks the work and activities being carried out
Development Team member adds a problem being faced to the Impediment Log
Development Team Member does development work
Development Team Member delivers a potentially releasable Increment of “Done” product
Stakeholders views deliverables as they are ready
Product Owner shares risk burndown chart with Stakeholders
Stakeholders change requirements
Scrum Teams asks the Scrum Guidance Body for advice
End-to-end quality assurance is conducted
Requirements change is deemed to be significant enough to stop the Sprint -> SPRINT IS TERMINATED
Scrum Core Team members to suggest changes or improvements to the product, service, or some other part of the projec
- the team may decide on a new feature to be added or modified to improve product performance
- market conditions could change
- organizational direction changes
- regulatory changes
Scrum Guidance Body may submit Change Requests:
- regulatory changes (privacy, security, etc)
- corporate directives for, security, etc
- benchmarks, best practices
- lesosns learned
Change requests become Epic or User Story
New requirements and changes added to the Prioritized Product Backlog may lower the priority of other existing User Stories in the Backlog
Scrum Team determines it has overestimated the effort during the Sprint, team can ask the Product Owner to add User Stories to Sprint
Someone addresses Product Owner to change a Product Backlog item’s priority (or move it out of sprint scope?)
- generates Change Request
New business requirements are added and existing requirements are properly documented and prioritized
(Scrum does not Time-box grooming exercises)
Product Owner develops a Product Backlog Review agenda
Product Owner invites limited stakholders + ALL Scrum Team members
Changes or updates to the backlog are discussed and incorporated into the Prioritized Product Backlog
Product components that have defects are incorporated into the Prioritized Product Backlog
Small change requests that do not have significant impact on the project be directly approved by the Product Owner.
Large change requests go to Stakeholders
verify the business justification for continuance. Still viable?
Team agrees on any changes
Sprint Retrospective is timeboxed
Invite Product Owner and relevant stakeholders
Demonstrate Deliverables
Product Owner accepts the Deliverables if they meet Acceptance Criteria and Done Criteria, User Stories as DONE or NOT DONE:
Done Criteria could include
- Reviewed by other team members
- Completed unit testing of the User Story
- Completion of quality assurance tests
- Completion of all documentation related to the User Story
- All issues are fixed
- Successful demonstration to stakeholders and/or business representatives
User Stories corresponding to rejected deliverables are added back to the Updated Prioritized Product Backlog
Stakeholders to reprioritize stories
Scrum Team submits Change Requests
Product Owner confirms the achievement of organizational benefits
A comparison of the number of issues encountered versus the number of User Stories completed can be done
discuss the lessons learned throughout the Sprint
document lessons learned to be applied to future Sprints
Discuss ways to improve processes and performance
Agree on Actionable Improvements
Scrum Guidance Body captures best practices to be used across all Scrum teams
Sprint is closed & New Sprint immediately starts
Product Owner assesses business impact
respective business unit and stakeholders participate
product increment is demonstrated to the Product Owner, sponsor, customer, and users
feedback from all the stakeholders is gathered
Quality assurance is demonstrated
stakeholders may submit Change Requests
Scrum Master ensures that the requirements and Acceptance Criteria are not altered, so that User Stories are accepted/rejected based on original requirements, not changed requirements
Ship Deliverables
Product Owner assesses the viability
Customers and Users review Deliverables
Product Owner ensures the delivery of the product
Working Deliverables Agreement documents the successful completion of the Sprint
Invite organizational stakeholders and Scrum Core Team members
retrospect the project
identify, document, and internalize the lessons learned
document of Agreed Actionable Improvements
Evaluate Product Owner:
- did they increase ROI?
- Or did they maximize business value for the project?
Evaluate Scrum Team:
- project deliverables are created?
- work is being performed according to plan
Evaluate Scrum Master:
- were Scrum processes correctly followed?
- Did development progress smoothly?
Scrum Guidance Body establishes metrics for developing role descriptions for Scrum Team members
Scrum Guidance Body recommends business justification techniques
Scrum Guidance Body updates risk checklists and prompt lists
Scrum Guidance body recommends confirming benefits realization
Product Owner confirms the achievement of organizational benefits
Scrum Guidance Body defines QA norms and processes
Stakeholders may submit Change Requests (go to Prioritized Product Backlog)
If Sprint Goal has become obsolete
Product Owner cancels the sprint
-
Completed and Done Product Backlog items are reviewed
-
If items are releasable, Product Owner accepts
-
Incomplete Product Backlog Items are re-estimated and put back on the Product Backlog
expensive rework that may result from a lack of clarity regarding expectations and requirements (from not doing enough user meetings)
Technical Debt:
- Quick-fix and building deliverables that do not comply with standards for quality, security, long-term architecture goals, etc.
- Inadequate or incomplete testing
- Improper or incomplete documentation
- Lack of coordination among different team members, or if different Scrum Teams start working in isolation, with less focus on final integration of components required to make a project or program successful
- Poor sharing of business knowledge and process knowledge among the stakeholders and project teams
- Too much focus on short-term project goals instead of the long-term objectives of the company. This oversight can result in poor-quality Working Deliverables that incur significant maintenance and upgrade costs.
Sustainable pace: accurate estimation, avoid intense periods of work
Conflicts: schedules, priorities, resources, reporting hierarchy, technical issues, procedures, personality, and costs
Different leadership styles in AI project owners
Project Stages: Forming — team has not yet encountered any difficulties Storming — power struggles, chaos, confusion Norming — Team begins to sort out their internal differences, find solutions to work together Performing — Team is cohesive, high performance. Members are efficient, peers, professional, consistent
There could be a Program Product Owner for a program or a Portfolio Product Owner for a portfolio.
Chief Product Owner
- prepares and maintains the overall Prioritized Product Backlog for the large project
- prioritizing competing requests raised by the Product Owners
- ensure various components are properly integrated and at appropriate times
Vendors
Sponsors
Scrum of Scrums
Customers do Monopoly Money exercise
Earned Value Analysis
Project Charter may provide official authorization to start work
Project Budget includes cost of people, materials and other expenses