scrum master
DESCRIPTION
TRANSCRIPT
Overview of Scrum3 roles
3 artifacts4 ceremonies
Scrum
https://www.realmdigital.co.za/post/whats-scrum-and-how-do-we-use-it/
Scrum Overview● Take a prioritized backlog of features● Deliver potentially shippable increments
of product every 1-4 weeks● Using 3 roles, 3 artifacts, and 4
ceremonies● suggested 5-9 people per team
○ scale via multiple scrum teams and scrum of scrums
● Owns the Product Backlog● Responsible for the business value of the
product (ROI)● Client or client proxy● Usually a business person or domain
expert● Answers questions about Backlog items● Needs to learn how to value at the
feature level vs the product level
The Product Owner
● Developers, Testers, DBAs, UX, Ops - no longer
● Responsible for completing tasks in the backlog
● No I in team, succeed or fail as a group● Self-organizing● Cross-functional
Team Member
● There to facilitate the Scrum● Protects the team from distraction● Removes impediments● Coach/mentor/servant leader● Works for the team
Scrum Master
● Created/groomed by the Product Owner● Ordered by business value● Priority can be a function of value,
technical scope, and technical necessity
Product Backlog
● The tasks from the product backlog that will be completed this sprint
● product backlog broken into manageable chunks
● 50-80% capacity
Sprint Backlog
● Shows progress through the sprint● A measure of success... (or defeat)
Burndown Charts
http://xprogramming.com/articles/bigvisiblecharts/
● Chickens and pigs● 3 Questions
○ What did I do yesterday?○ What am I planning to do today?○ Do I have any impediments?
● Discussions should be reserved to interested people in separate meetings
Timeboxed to 15 minutesOccurs daily
Daily Scrum (Standup)
● Planning Poker● 2 parts
○ Estimate features, talk about why they are important (What and Why)
○ Break down the features into small tasks and grab highest priority features until out of capacity (How)
Each part timeboxed to 1 hour per week in sprint (ex. 2 week sprint, part 1 - max 2 hours, part 2 - max 2 hours)Occurs first day of sprint
Sprint Planning
● Show working software to stakeholders● Take questions and feedback
Timeboxed to 1 hour per week in sprint (ex. 2 week sprint max of 2 hours)Occurs last day of sprint
Sprint Review/Demo
● Extremely important● Reflect on how the sprint went● Identify things that need to change
Timeboxed to 45 minutes per week in sprintOccurs last day of sprint after Sprint Demo/Review
Sprint Retrospective
● Keep to < 10% of capacity● Break down, analyze, estimate large
stories● Either a meeting or team available to
help product owner
Optional Sprint Task - Product Backlog Refinement/Grooming
so what else did we learn
That's All Scrum Is
● The team must agree to a definition
● Coded, unit tested, accepted by PO● + automated acceptance test in place● + documented● + ready for deploy to production
Definition of Done
● Up to the team to choose appropriate practices
● Start with 2-week sprints, adapt● Don't start or end sprints on Monday or
Friday (they're the most likely vacation days)
● Automated Acceptance and Unit Tests○ TDD and ATDD/BDD
● Continuous Integration
Recommended Practices
● Pair Programming● Planning Poker● User Stories● Communities of Practice
Recommended Practices(Cont.)
● Seed the product backlog● Build/grab a team● Make decisions on team rules, definition
of done, practices, technology stack● Setup version control, continuous
integration, continuous delivery, architectural skeleton
Sprint 0/Iteration 0/Project Inception
● The team decides them● Examples:
○ Late to meeting: penalty○ Leaving the build broken: penalty○ No laptops or phones at meetings (except
driver)○ Definition of done○ Respect others - keep it short, 1 person
talking at a time, project your voice if on conference call
Team Rules
● Relative○ Story points, T-shirt size, etc.○ Pros:
■ Relative size stays the same, hour estimates per unit of size should improve
■ Can't be mapped between teams○ Cons:
■ Harder to learn how to do■ Can't be mapped between teams
Relative vs Hour Estimation
● Hours:○ Pros:
■ Easier to grasp○ Cons:
■ Difference between senior and junior estimates■ May be taken as a commitment rather than an
estimate
Relative vs Hour Estimation
● Other departments don't accept the Scrum practices○ Anything can go on backlog, but nothing will
be worked immediately○ Non-agile contracts○ Dependencies with non-agile teams○ Annual reviews involve ranking people
against one another instead of on team success or knowledge transfer
Pain Points
● Product Owner isn't full time with team● We sometimes let sprints go long● We don't do Daily scrum or sprint
retrospective● We still throw code over a wall to testers● Team split between multiple projects
● Not always bad ... but not Scrum
Scrum, But...
● Incorrect metrics● Hiring● Furniture police● Hero team members● Training
All Dysfunction is Organizational or Process Related
● Co-located team - 0.6x● Large scale (Scrum of scrums) - 1.4x
Time Bonus/Penalties
Number of Projects● 1● 2● 3● 4● 5● 6
The Myth of MultitaskingEffective Hours per Day● 5-6● 4● 3● 2.5● 2● 1
via Slack by Tom DeMarco
Overtime is a Lie● Overtime over a week will regress to the
mean○ 1st week you'll get extra capacity○ After that at best you're getting 40 hours for
the 50 or 60 you're paying for● More defects● Employee morale declines
● Succeeding with Agile by Mike Cohn● Agile Estimating and Planning by Mike Cohn● User Storied Applied by Mike Cohn● Agile Retrospectives by Esther Derby and Diana Larsen● Agile Coaching by Rachel Davies and Liz Sedley● Agile Software Development with Scrum by Ken
Schwaber and Mike Beedle● http://www.mountaingoatsoftware.com/topics/scrum● http://scrumfoundation.com/library
Further References