the product backlog - scrum · •you get a tale of corrections that has an impact on future...

19
Contact information Email: [email protected] Twitter: @rennebo Phone: +45 60 84 85 00 Invite the tester to the party Global Scrum Gathering – Prague 2015

Upload: others

Post on 11-Jun-2020

1 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: The Product Backlog - Scrum · •You get a tale of corrections that has an impact on future sprints •Create software iteratively •User accept criteria is defined for each User

Contact informationEmail: [email protected]: @renneboPhone: +45 60 84 85 00

Invite the tester to the partyGlobal Scrum Gathering – Prague 2015

Page 2: The Product Backlog - Scrum · •You get a tale of corrections that has an impact on future sprints •Create software iteratively •User accept criteria is defined for each User

About me

Allan Rennebo Jepen

• Agile Transformation Coach

• People enthusiast

• Former IT-everything (almost)

• Founder of Agile Copenhagen

• Senior Partner and Founder of Coregile

• Have a bunch of badges

Page 3: The Product Backlog - Scrum · •You get a tale of corrections that has an impact on future sprints •Create software iteratively •User accept criteria is defined for each User

Who are you?

• How Scrum mature is your organization?

• How extensive is your personal Scrum experience?

• What is your current role?

Page 4: The Product Backlog - Scrum · •You get a tale of corrections that has an impact on future sprints •Create software iteratively •User accept criteria is defined for each User

What are your biggest frustrations?

Page 5: The Product Backlog - Scrum · •You get a tale of corrections that has an impact on future sprints •Create software iteratively •User accept criteria is defined for each User

My promises to you

• You will get practical inspiration on how you can include the tester - starting Monday morning.

• You will be able to help eliminate the need for "Quality Control".

• You will be able to turn the battle between developers and testers into a collaborative process.

Page 6: The Product Backlog - Scrum · •You get a tale of corrections that has an impact on future sprints •Create software iteratively •User accept criteria is defined for each User

Let’s get startedWith a tour in the real world

Page 7: The Product Backlog - Scrum · •You get a tale of corrections that has an impact on future sprints •Create software iteratively •User accept criteria is defined for each User

Production line mentality

• Testing is always down prioritized (it comes last)

• Most solutions are inferior (if not completely useless)Res

ult

• Talk to the sponsors

• Analyze what you need to build (User Requirement Specification)

• Create solution design

• Build the solution

• Test it

• Go Live

The

flo

w

Page 8: The Product Backlog - Scrum · •You get a tale of corrections that has an impact on future sprints •Create software iteratively •User accept criteria is defined for each User

Iterative production line

• There is very little room for the team to navigate

• Developers don’t take responsibility for quality

• The solution is never in a stable state

• Tests only verify the requirements – not that the needs are met

• Software is created as an iterative process

• Define accept criteria for all requirements in great detail

• Design test cases as part of the User Story definition

• Testers verify the solution after the Sprint is completed

Res

ult

The

flo

w

Page 9: The Product Backlog - Scrum · •You get a tale of corrections that has an impact on future sprints •Create software iteratively •User accept criteria is defined for each User

Scrum (with waterfall elements)

• Testers are always bored in the beginning of a Sprint

• Towards the end of a Sprint the testers are overloaded

• The Sprint ends before all bugs are corrected

• You get a tale of corrections that has an impact on future sprints

• Create software iteratively

• User accept criteria is defined for each User Story

• Developers evolve the solution as a creative agile team

• Testers verify the solution when developers have built it

Res

ult

The

flo

w

Page 10: The Product Backlog - Scrum · •You get a tale of corrections that has an impact on future sprints •Create software iteratively •User accept criteria is defined for each User

A different worldHow do we get there?

Page 11: The Product Backlog - Scrum · •You get a tale of corrections that has an impact on future sprints •Create software iteratively •User accept criteria is defined for each User

Pop Quiz

• Who do you consider your primary stakeholders?

• What does it take to be done in your team?

• Why do you perform testing?

Page 12: The Product Backlog - Scrum · •You get a tale of corrections that has an impact on future sprints •Create software iteratively •User accept criteria is defined for each User

A

Imagine you are buying a new car

Page 13: The Product Backlog - Scrum · •You get a tale of corrections that has an impact on future sprints •Create software iteratively •User accept criteria is defined for each User

Are you happy?and this is what you get delivered

Page 14: The Product Backlog - Scrum · •You get a tale of corrections that has an impact on future sprints •Create software iteratively •User accept criteria is defined for each User

Use of the Scrum board

• Get stuff done (and not just coded)

• Limit the work in progress

Page 15: The Product Backlog - Scrum · •You get a tale of corrections that has an impact on future sprints •Create software iteratively •User accept criteria is defined for each User

Adjust the flow

Developers picks a task

Developers explains the solution to tester

Tester validates and provide feedback

Developers and tester agrees

Developers implements while tester prepares

Tester verifies the implementation

Tester and developer updates the board together

Page 16: The Product Backlog - Scrum · •You get a tale of corrections that has an impact on future sprints •Create software iteratively •User accept criteria is defined for each User

Wrap it up

Page 17: The Product Backlog - Scrum · •You get a tale of corrections that has an impact on future sprints •Create software iteratively •User accept criteria is defined for each User

Sprint Review

• Starting Monday morning (or maybe even Thursday):• Make the tester as a central part of the team collaboration by making the test

process part of the development flow(If you don’t have limits on Work in Progress, it will help you to introduce them

• Eliminate the need for "Quality Control“:• By reducing risk!

When the tester is a natural part of the development flow, you have addressed the issues in real time.(You are not able to “repair the car while driving”)

• Enable collaboration between developers and testers:• I hope that part is obvious

Page 18: The Product Backlog - Scrum · •You get a tale of corrections that has an impact on future sprints •Create software iteratively •User accept criteria is defined for each User
Page 19: The Product Backlog - Scrum · •You get a tale of corrections that has an impact on future sprints •Create software iteratively •User accept criteria is defined for each User

Contact informationEmail: [email protected]: @renneboPhone: +45 60 84 85 00

Invite the tester to the partyGlobal Scrum Gathering – Prague 2015