agile project delivery using scrum n.
Skip this Video
Loading SlideShow in 5 Seconds..
Agile Project Delivery Using Scrum PowerPoint Presentation
Download Presentation
Agile Project Delivery Using Scrum

Loading in 2 Seconds...

play fullscreen
1 / 70

Agile Project Delivery Using Scrum - PowerPoint PPT Presentation

  • Uploaded on

Agile Project Delivery Using Scrum. Training Goals. Understand Scrum at a high level Understand the basic principles and practices of Scrum Appreciate how scrum processes can help teams practice self-directed leadership Understand that our learning will be iterative.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

Agile Project Delivery Using Scrum

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
training goals
Training Goals
  • Understand Scrum at a high level
  • Understand the basic principles and practices of Scrum
  • Appreciate how scrum processes can help teams practice self-directed leadership
  • Understand that our learning will be iterative
think out of the box
Think “out-of-the-box”
  • Scrum is founded on sound industry accepted project management practices
  • Open our mind to new concepts.
all agile frameworks share a common philosophy
All Agile frameworks share a common philosophy
  • The Agile Manifesto

Individuals and Interactions

Working Software/Product

Customer Collaboration

Responding to Change

what is scrum
What is Scrum?

Scrum is an iterative framework for developing any product or managing any work.

  • Iterative and incremental
    • Project progresses in series of short iterations
    • Product increment delivered at end of each iteration
  • Self organizing & cross-functional team
    • Direction provided primarily at beginning and end of each iteration
    • Team works collectively to plan and organize their work
  • Very collaborative
    • Makes everything highly visible through constant communication and collaboration.
scrum components
Scrum Components
  • Major components of Scrum
  • Release
    • Completion of a major component of work.
    • Consists of multiple iterations
    • Release Preparation occurs at the beginning of a release
  • Iteration
    • Time box (10-20 days)
    • Completion of a small increment of work
    • Multiple iterations in a release
project team
Project Team

Iteration Master

End Users

Scrum Team

Dr. Quicksall & “Sampling Team”

Product Advisor

(Faculty/TA Coach)

roles product advisor aka product owner
Roles – Product Advisor (aka Product Owner)
  • Coaching Responsibilities
    • Trains and Mentors the Scrum team
    • Guides the Iteration Master to follow and maintain the process
  • Defines the features of the product
    • What Stakeholders want
    • What goes into the product
  • Decides on the release dates and content
  • Responsibilities
    • Prioritizes the user stories in the Product Backlog
    • Ultimate decision maker on requirements issues
    • Negotiates Acceptance Criteria for work results

(Faculty/TA Coach)

roles iteration master aka scrum master
Roles – Iteration Master (aka Scrum Master)
  • Member of the Scrum team
  • Facilitator, not manager
  • Keeps the process moving
    • “Enforces” the Scrum framework(w/help of coaches)
    • Ensures full-team involvement in all meetings
    • Keeps everything visible
  • Advocate for improved practices
  • Communicate impediments and successes
  • Tracks and communicates progress of team
roles scrum team
Roles – Scrum Team
  • Cross functional, self organizing and self managing
  • Self motivated to help the team succeed
  • Works to solve problems & produce product increments
  • Follows Scrum practices and organizational policies
  • Innovative
    • Looks for ways to design, build, document with less effort
    • Looks for ways to create a better product
    • Adds new ideas or issues discovered to the Product Backlog
  • Stays focused on the iteration goals and commitments
self directed teams
Self-Directed Teams
  • Responsible for planning, managing and executing work
    • Team plans work together
    • Team determines approach for completing work
    • Each person volunteers for tasks. Tasks are not assigned.
  • Works together to meet goals
    • Step up to help team members succeed
    • No “not my job”
    • Provide solutions and feedback
    • Abide by team decisions
  • Responsible for team success or failure


Release Preparation

release preparation
Release Preparation
  • Visioning – Team collaborates to establish the detailed project vision and understand the expected outcomes of the project.
  • Roadmapping- Map out the long term plan for how the product will evolve over time and establish optimal release windows
  • User Story Workshop – Create, estimate, and prioritize user stories for the project
  • Release Planning – Review the Product Backlog to plan the release timeline and iteration planning activities
  • Overview
    • Initial meeting with the Scrum team to review from a business perspective, collaborate, and agree on the…
      • … goals, value, vision for completing the project
      • … scope, stakeholders, architecture impacts, and tool requirements.
    • Opportunity to agree on the team working agreement
  • Outcomes
    • Team alignment on project scope and expectations
    • Team Working agreement
    • Initial Issues and Risks
vision statement
Vision Statement

Team collaborates to establish the project vision and understand the expected outcomes of the project.

Some team choose to create a vision statement:

For research scientists who would like to remotely access a well, sample the water, and test it on site, the initiative will provide researchers a robot that can self-navigate a variety of terrains, sample from various well types, and perform on-site testing and remediation

  • Overview
    • Opportunity to create a Product Roadmap
      • Shows how the product and architecture may evolve to deliver desired features and benefits to specific user or customer groups.
    • Determine high level milestones that could affect the project.
      • Can include product release dates, infrastructure upgrades, important customer milestones or any other significant date that could impact the project.
    • Determine any dependencies between milestones, architecture, and features to be developed for customers
  • Outcomes
    • A long term view of the Product Roadmap with any dependencies associated with customers, features, events, rhythms, and the architecture.
roadmapping simple template
Roadmapping – Simple template
  • Recommendation of 5 rows labeled as indicated. Add other rows as needed
  • Low tech (sticky notes) good way to collaborate

HQ TM and Selected Field

Rel 2.2 Enabled

SSO Web-based Reporting



Xcelsius / Weblogic / Oracle

Master Geography

Freeze Aug 7 and Sept 7

Freeze May 6th

Release 2

Release 2.2

Release 3

Release 1



Release Preparation

User Story Workshop

user story workshop
User Story Workshop
  • The User Story Workshop consists of 3 sections
    • User Story Creation
      • Project team creates user stories
    • User Story Estimation
      • Project team estimates the story points for each user story
    • User Story Prioritization
      • Product Advisor with input from the Scrum team places the user stories in priority based on customer need and business value
user story creation
User Story Creation
  • Overview
    • Initial opportunity for the team to review, discuss, and document requirements for the project as user stories.
    • In Scrum a requirement is documented as a user storywhich is placed in the product backlog. It is the responsibility of the Product Advisor to review, prioritize and approve all user stories placed in the product backlog.
  • Outcomes
    • An initial set of user stories for the project
user stories backlog
User Stories – Backlog
  • Product Backlog
    • List of all requirements in the form of user stories
    • Prioritized by the Product Advisor
    • Items can only be added or removed by the Product Advisor
  • Iteration Backlog
    • User stories chosen to be worked in this iteration
    • Created by the team from the product backlog
    • Highest priority product backlog items





user stories key features
User Stories - Key Features
  • Key Features
    • High-level features of the product being developed
    • Defined in Visioning
    • Used as a starting point to create user stories
user stories what are they
User Stories – What are they?
  • Easy to use and manage approach to writing requirements
  • A short, plain-language description in terms of customer value
  • Created during story-writing workshops at the beginning of the project, and then augmented during the project
  • Augmented by screen mock-ups, design diagrams or any other artifact that enhances understanding of the story.
  • Anyone can write a user story
user stories why user stories
User Stories – Why User Stories?
  • Stories are easy to understand
    • Developers and customers understand them
    • People are better able to remember events if they are organized into stories
  • Stories are the right size for planning
  • Support and encourage iterative development
    • Can easily start with very large stories and epics then break down close to development time
  • Stories support flexible and efficient development
user stories should follow invest
User Stories – Should follow INVEST

Avoid dependencies on other stories

Leave or imply some flexibility

Identify value to the customers, not developers

Enough detail to estimate.

Must get done in a single iteration

Acceptance criteria should be identified







INVEST coined by Bill Wake

user stories personas
User Stories - Personas
  • Personas
    • A role identified that will use or interact with the developed product
    • Can be the product itself or components of the product
    • Can be real people or roles in an organization
user stories format
User Stories - Format
  • User Stories are comprised of 3 parts
    • As a/an <persona>
    • I want/I need <function>
    • So that <reason>
  • As an Unregistered User I want to be able to enter my name and contact information so that I can create an account to become a registered user.
  • As an Administrator I need a report so that I can see who is a registered user for my application.
  • As a Registered User I need to change my password so that my personal information is secure.
  • As an Purchaser I want to create a wish list of books so that I can return to purchase them at a later time.
user stories quicksall org examples1
User Stories – Examples
  • As Uganda Research Scientist I want a robot that can autonomously maneuver from one location to another on a level playing field so that I have the ability to get well samples from Uganda.
  • As Professor Quicksall I want a robot that can differentiate the playing field boundary from the obstacle so that I can identify the location of the wells.
  • As Professor Quicksall I want a robot that can identify the obstacle by reading a series of tape lines so that I can determine which well has been encountered.
user stories confirmation
User Stories - Confirmation
  • Confirmation methods are written on the back of the card
    • Include conditions of satisfaction or acceptance criteria
    • Essentially test cases that address various scenarios and questions
user stories spur conversation
User Stories – Spur Conversation
  • The card only covers the most basic information
  • The next level of detail comes in conversations between the Product Advisor and the Scrum team
  • The conversations take place
    • At Project inception, during story writing sessions
    • During the Iteration Planning Meeting
    • During the iteration
quicksall org user story creation
Quicksall.orgUser Story Creation
  • Take 30 minutesto create user stories

For research scientists who would like to remotely access a well, sample the water, and test it on site, the initiative will provide researchers a robot that can self-navigate a variety of terrains, sample from various well types, and perform on-site testing and remediation

Value Statement

  • Personas
  • reps
  • Research Scientists
  • Create others if needed


Release PreparationUser Story Estimation

user story estimation
User Story Estimation
  • Overview
    • User Story Estimation is the initial opportunity for the Product Advisor and Scrum team to review and estimate the relative user story points for each user story.
  • Outcomes
    • An initial set of estimated user stories
user stories using story points
User Stories – Using Story Points
  • User stories are estimated in user story points not time.
  • Advantages to story points versus time estimates
    • Estimating is very quick because it is an intuitive estimate
    • The estimate indicates an item’s size relative to another, and does not give the illusion of being precise.
    • Estimating time can be hard, but we are all good at comparison.
user stories what is estimation
User Stories – What is estimation?
  • Notes on Story Points
    • Scrum team does the estimation, not the Product Advisor
    • An estimate of size, risk, and complexity – NOT TIME
    • Relative sizing of items is the key
    • Points cannot be transferred between teams
    • Points are based on teams that are stable throughout the development process









user stories estimation planning poker
User Stories – Estimation “Planning Poker”
  • Planning Poker
    • Collaborative estimation method to help the team align on the relative size and complexity of each user story
    • uses multiple card decks each consisting of 8 cards numbered 1, 2, 3, 5, 8, 13, 20, and 40.
user stories planning poker rules
User Stories – “Planning Poker” Rules
  • Iteration Master selects and reads the highest priority user story that has not already been estimated
  • Team briefly discusses the user story
  • Scrum team members SIMULTANEOUSLY show their selected card representing the story point estimate
    • The high and low team members in turn discuss why they selected the value they did (try to keep to less than 5 minutes for the total discussion)
    • The Scrum team then re-votes based on the views presented
  • The Iteration Master writes the value on the card and this becomes the story point value
  • Repeat the process for the next highest priority user story


Release PreparationUser Story Prioritization

user story prioritization
User Story Prioritization
  • Overview
    • Opportunity for the Product Advisor, with input from the Scrum team to review and place the user stories into a prioritized order based on business value and customer need.
  • Outcomes
    • A set of prioritized project user stories
user stories prioritization
User Stories - Prioritization
  • User stories are prioritized by the Product Advisor with input from the Scrum team.
  • Highest priority user stories should be delivered during the earlier iterations
  • Prioritization methods
    • Business Value
    • Product Advisor opinion
    • Technical Feasibility
    • Internal voting
    • Survey customers
quicksall org estimation prioritization
Quicksall.orgEstimation & Prioritization
  • Use the Antique Dealer ecommerce user stories already created
  • Take 20 minutesto estimate the story points for each
      • Review the user stories created previously with the group
      • Estimate the user stories using “Planning Poker” cards
  • Take 10 minutesto prioritize the created user stories
      • Review the user stories previously estimated
      • Product Advisor and Scrum team prioritize the user stories based on what needs to be completed first or has the most business value.
      • Place the user stories on the table in priority order


Release PreparationRelease Planning

release planning
Release Planning
  • Overview
    • Establish a plan and goals that the team can understand and communicate relative to the release of the project
    • The release plan establishes the goal of the release, the major risks, the features and functionality that the release will contain. It also establishes a probable delivery date
  • Outcomes
    • A determination of the user stories required for a release
    • The timing required for a release and functionality available
    • Documented activities required to perform a release
release planning determine iterations
Release Planning – Determine Iterations
  • Scrum team determines how much work can be accomplished in each iteration.


Iteration ExecutionIteration Planning

iteration execution
Iteration Execution
  • Overview
    • Where the majority of work for the project gets completed
    • Each task created for the iteration is selected by a team member as a work function
    • During this time that team member is responsible for working toward completing that task
  • Outcomes
    • Working product, reviewed, and accepted by the Product Advisor
    • Team has reflected on the work and has a plan to improve
iteration sessions
Iteration Sessions
  • A iteration is a time-boxed iteration of development. Consists of:
    • Iteration Planning
    • Daily Standup Meeting
    • Iteration Review Preparation
    • Iteration Review
    • Retrospective
  • Iterations occur one after another
iteration planning
Iteration Planning
  • Overview
    • Product Advisor
      • Communicates the Iteration Goals
    • Scrum Team
      • Selects highest priority user stories from the product backlog
      • Writes out the tasks needed to complete those user stories
      • Estimates the number of hours each task will take to complete
      • Agrees as a team to accept the user stories and work associated with the iteration.
  • Outcomes
    • Scrum team agrees on work to be done in the iteration
iteration planning understand select commit
Iteration Planning – Understand, Select, Commit
  • Understanding
    • First half of Iteration Planning addresses all of the team’s questions
      • Do they understand the items at the top of the prioritized Product Backlog
  • Selecting
    • Selecting user stories from the prioritized Product Backlog
    • Discussion then moves to task breakdown, design, other implementation issues before time box ends
    • Scrum team associates an hourly estimate for each task
  • Committing
    • Team commits to the work selected
iteration planning creating tasks
Iteration Planning – Creating Tasks
  • For each user story selected the Scrum team creates the tasks to complete the associated user story
  • Tasks typically correspond to “standard” activities
    • Designing a new database schema
    • Coding / Building
    • Updating documentation
    • Testing
  • Once the task is created an estimation of the number of hours required to complete that task is written on the task card
iteration planning task breakdown
Iteration Planning – Task Breakdown
  • Tasks are written for each User Story
iteration planning commit to iteration
Iteration Planning – Commit to Iteration

Scrum Team:

  • Assesses all the work that needs to be completed for the iteration
  • Takes into consideration all tasks for the iteration
  • Determines how much time each team member can devote to completing tasks
  • Adjusts user stories and associated tasks (add or remove), as needed to match capacity of team
  • Commits to completing all the work for the iteration.
quicksall org iteration planning Iteration Planning
  • Use the user stories already created, estimated, prioritized
  • Take 20 minutesto plan the first iteration
  • Exercise Steps:
    • Select a user story from the Product Backlog for Iteration 1
    • Write out the tasks that are needed to complete the user story
    • Estimate how many hours each task will take to complete


Iteration ExecutionDaily Standup

daily standup
Daily Standup
  • Overview
    • Where the Scrum team meets to discuss
      • How the iteration is progressing
      • Any obstacles encountered since the last meeting
      • Improve communications, eliminate other meetings, identify and remove impediments, highlight and promote quick decision-making, and improve everyone’s level of project knowledge
  • Outcomes
    • Updated tasks
    • Updated iteration burn down chart
daily standup an important 15 minutes
Daily Standup – an important 15 minutes
  • Same time and location every day
  • Exchange of information, not traditional reporting
  • Focused on What, not Why or How
  • Scrum team members answer 3 questions
    • What did I do since the last Daily Scrum?
    • What will I do before the next Daily Scrum?
    • What is blocking me from being successful?
iteration burndown chart
Iteration Burndown Chart
  • How do we measure progress during an iteration?

Ideal Progress

Daily Progress



Iteration ExecutionIteration Review

iteration review preparation
Iteration Review Preparation
  • Overview
    • The objective is to prepare for the Iteration Review meeting. At this meeting all user stories selected for the current iteration are reviewed and determined if they are completed and ready to be demonstrated to the Product Advisor and Stakeholders
    • Last event for the iteration with no additional work being performed
  • Outcomes
    • Team determines the agenda for the Iteration Review
    • Team determines the logical order for discussing the completed user stories during the Iteration Review
    • Team decides who will demonstrate each user story. It’s a best practice to have each team member present in the meeting
iteration review
Iteration Review
  • Overview
    • Held at the end of each iteration.
    • Informal meeting to demonstrate completed functionality
    • The Scrum team and Product Advisor collaborate about what was completed during the iteration and what to do next.
    • Product Advisor decision on the next steps for the project: Continue, Stop, or Release
  • Outcomes
    • A review of all user stories selected for the iteration
    • Feedback and acceptance/rejection of user stories by Product Advisor
    • Updated user stories and/or action items
iteration review quicksall s decision
Iteration Review – “Quicksall’s” Decision
  • Product Advisor determines what direction the project should take based on the demonstrated user stories, and input from the team and stakeholders.
      • Continue current Product Backlog
      • Add user stories and reprioritize
    • STOP
      • Terminate the project
      • Sufficient functionality has been demonstrated to contain value for the stakeholders such that the product can be released in the demonstrated state


Iteration ExecutionRetrospective

  • Overview
    • An opportunity for the team to look back on the last iteration with the intention of learning from their experience and applying this learning to future iterations
    • A facilitator encourages the Team to reflect and inspect how the last iteration went in regards to people, relationships, process, and tools.
    • Identify actionable improvement measures that can be implemented in the next iteration by the team
  • Outcomes
    • Action items for improving the effectiveness of the team and the process
retrospective when why what
Retrospective – When? Why? What?
  • When?
    • After every iterationto handle mid-course adjustments, gather metrics, and improve
  • Why?
    • Reflection on the process
    • Collect feedback during the life of the project
    • Focus is on what we can learn from what happened
    • What?
    • Topics can include anything associated with success of project; people, relationships, process, tools, iterations, etc.
retrospective action plans
Retrospective – Action Plans
  • Once all the information is collected for each of the questions the facilitator walks the team through the comments
  • The team reviews the comments and determines an Action Plan for improvement
  • Stop
  • ~ ~ ~ ~ ~ ~ ~
  • ~ ~ ~ ~ ~ ~ ~
  • ~ ~ ~ ~ ~ ~ ~
  • ~ ~ ~ ~ ~ ~ ~
  • ~ ~ ~ ~ ~ ~ ~
  • ~ ~ ~ ~ ~ ~ ~
  • ~ ~ ~ ~ ~ ~ ~
  • Start
  • ~ ~ ~ ~ ~ ~ ~
  • ~ ~ ~ ~ ~ ~ ~
  • ~ ~ ~ ~ ~ ~ ~
  • ~ ~ ~ ~ ~ ~ ~
  • ~ ~ ~ ~ ~ ~ ~
  • ~ ~ ~ ~ ~ ~ ~
  • ~ ~ ~ ~ ~ ~ ~
  • Continue
  • ~ ~ ~ ~ ~ ~ ~
  • ~ ~ ~ ~ ~ ~ ~
  • ~ ~ ~ ~ ~ ~ ~
  • ~ ~ ~ ~ ~ ~ ~
  • ~ ~ ~ ~ ~ ~ ~
  • ~ ~ ~ ~ ~ ~ ~
  • ~ ~ ~ ~ ~ ~ ~
  • Action Plan
  • ~ ~ ~ ~ ~ ~ ~
  • ~ ~ ~ ~ ~ ~ ~
  • ~ ~ ~ ~ ~ ~ ~
  • ~ ~ ~ ~ ~ ~ ~
  • ~ ~ ~ ~ ~ ~ ~
  • ~ ~ ~ ~ ~ ~ ~
  • ~ ~ ~ ~ ~ ~ ~