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