Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Agile/Scrum SDPHP

No description

Business .com

on 25 July 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Agile/Scrum SDPHP

It's the Features, Stupid:

How scrum helps dev teams deliver features on time
By: Tim Sorweid
ScrumMaster for
The Old Way
A classically linear and sequential approach to software design and systems development, each waterfall stage is assigned to a separate team to ensure greater project and deadline control, important for on-time project delivery.
Software development method without an actual defined method – team members do whatever they feel is right.
Problems with Waterfall
Cone of uncertainty
Problems with Waterfall
Monolithic Scope Documents
Inflexible business requirements
Distant delivery date
Coding Death-March
Limited customer collaboration
Have to get it right the first time
Problems with Cowboy Coding
No transparency to customer or management
Limitations of the sole developer
Gantt Charts
Problems with Waterfall
"The human mind is an iterative processor. It never does anything precisely right the first time. What it does consummately well is to make a slight improvement to a flawed product." - Tom DeMarco

Agile Software Development
Only concerned with delivering the top priority features, while keeping a distant eye on the whole project
How often do 4 month-long projects end up looking how they were intended from the onset anyways?
Develop, test, & deliver features every two weeks
Re-prioritize, pivot, and repeat
Empowered Teams
*swing by our open workspace
Organized reflection after every iteration
Process by the team for the team
Never-ending quest for the "perfect" iteration
What is Scrum?
Daily team standup
What did I do yesterday?
What am I doing today?
What roadblocks are in my way?
Daily Scrum
Sprint Planning
Project Grooming
The Players
Product Owner
Represent the customer or business needs
Works with stakeholders on developing user stories
Communicates changes to stakeholders
Prioritizes product backlog
Clarifies requirements
The Players
Deflects outside forces from distracting the team
Helps navigate or plow through roadblocks
Facilitates collaboration
Ensures agile cadence is adhered to
Is in constant communication with Product Owner
The Players
The Team
UI Engineers
QA Engineers
Product Manager
Sprint Cadence
Sprint Planning
Who: Product owner, ScrumMaster, team (perhaps stakeholders)
What: Team commits to a list of features it will work on developing
Tip: Sprint Planning is often used for identifying scope & defining details. Avoid this by doing regular story grooming
Backlog Grooming
Pop stories off the top of the backlog
Discuss details, ask questions, refine requirements
Apply story points
note: Grooming is the unsung hero meeting of the agile cadence. Avoid at your own peril
Walk-through of all new features to all of the defined stakeholders
Show how code can solve a realistic user problem
Features demoed will be a part of release
Tip: Demo should not be the first time that a stakeholder sees the feature
Code Release
Feature branches are closed, release branches are created, code is pushed into production.
Tip: Though we all know what is being released, it's best the team gathers around a conference room until code is deployed; aka warroom
Who: Product owner, ScrumMaster, team (definitely not stakeholders)
What: Team identifies what did and didn't go well during the previous iteration and what to focus on for the next
Tip: Find an activity which naturally engages the team and encourages feedback
"Working software is the primary measure of progress"
Tip: Demo gives the team the chance to show everyone their hard work. Be sure to rehearse.
Tools & Terminology
User Story
Short description of a feature told from the perspective of a person who desires the new capability
Example: As a <type of user>, I want <some goal> so that <some reason>.
Epic Story
Large user story
User Acceptance Criteria
Series of (testable) conditions which indicate objectives for a story's completion
Tips: Use the UAC to help shape your demo
In Practice....
Epic: As a registered member, I want to manage my photos so I can share them with my friends
Story: As a registered member, I want to upload a photo so I can add it to my album
Can select multiple photos
Photo is resized to fit
Photo is compressed to x%
User receives confirmation message
Story Points
An arbitrary number used to indicate effort for completion
3 - two uninterrupted days
2 - one uninterrupted day
1 - half uninterrupted day
0 - couple hours
Tip: Don't let the business equate points to billable hours
After a few iterations, the average amount of completed story points is the team's velocity
Used to help aid commitment and project burn-down
Tip: usually takes 3 iterations with the same team to get a good velocity
Burn-down Chart
Tip: only deduct points when user story is code reviewed, QA'd & approved by the stakeholder
Product Backlog
Prioritized list of user stories from which each iteration spawns
Backlog is the Product Owner's most powerful weapon
Must be reasonably groomed to be effective
Visual representation of user stories' progress in a sprint
Tip: Organize daily scrum around your wallboard to aid discussion
Define 'Done'
Let the team define the process
Always focus on the user stories (aka features)
Celebrate a story's completion
Communicate changes in timeline to ScrumMaster through Product Manager (early)
Keep the product backlog groomed
Release code every iteration
Be realistic: Remind Product/Customer that they have the power to define priorities, but each new feature pushes something else down
A sprint is not a mini-waterfall
Don't have to be textbook agile. Take what you like
Scrum: Get some.
Common Problems With Software Development
We traditionally view products as one large deliverable
It's hard to determine priority
We lose sight on who will be using our code
Business goals change faster than we can get projects to market
Deadlines are based off of S.W.A.G.
About Me:

BS in Computer Science
Worked as Director of Web Development for 5 years
2 years and counting as ScrumMaster for
Helped organize engineering team into multiple agile dev teams
Certified ScrumMaster
By Tim Sorweid
ScrumMaster for

Product manager comes to your dev team with a 20 page scope document. He asks you to put together a plan of execution and date of completion.

Your team identifies what it feels are all of the tasks necessary to meet the requirements. You provide a date 5 months in the future, the week before Christmas.

It's December 25th. What do you think happens?
Retrospectives at BDC
Red Post-it Notes: Two things that need improvement
Yellow Post-it Notes: Two things that went well
Hand the reds ones to the person on your left, Yellow to the right
Each person interprets the notes in front of them
Document items to continue, start, & stop doing
Full transcript