dcbadd2015 sticky changes

“STICKY” CHANGES

Presented(By(

Manjit(Singh(&(

Kawaldeep(Chadha((

www.agilious.com @agilious

2 2

20 years of software development, management

& delivery experience

Consulted, trained, or coached with people and

teams from IBM, SRA, UMUC, NSF, DOJ, DOL, NSF

20 years of agile experience; started using XP in

2000 at IBM

MS Computer Science at SUNY Albany

Founder & organizer DC Agile User Group

Agile Coach & Trainer Manjit

Manjit(Singh,(Enterprise(Agile(Transformation(Coach(President,(Agilious(LLC(


3 3

25 years of software development and

management experience in Defense and Commercial

Industry

9 years of agile SCRUM experience

Certified Scrum Master Certified Scrum Product

Owner Certified Agile Team

Facilitator

Senior Scrum Master and Agile Team Coach

Kawaldeep

Kawaldeep(Chadha(Sr.(Scrum(Master(&(Agile(Team(Coach(


4

Accelerating Agility

Agile Consulting

4

Coaching

Mentoring

High Performing

Team

Training

Engineering Practices

Agile Transformation •  Team and One-on-One

Agile coaching

•  Customized Agile Methodology training

•  Product Owner/Scrum Master/Team Member mentoring

•  Practical, hands-on learning of Software Engineering Practices (TDD, ATDD, Continuous Integration, Pair Programming, etc.)


5

Agile Product Development

Software Products

Mobile Apps

Web Apps

Enterprise Applications

Web Sites



6

Agile Training

Roles

•  Agile Business Analyst •  Agile Product Ownership •  Agile Team Facilitation •  Agile Project Management

Enginee-ring

•  Agile Testing •  Agile Test Automation •  Agile Programing Techniques

Team •  Agile Fundamentals



7 7

Making Changes “Stick”

http://getbuttonedup.com/wp-content/uploads/2013/02/Multitasking-Sticky-Notes.jpg


8 8

What Changes?

http://www.webascender.com/Portals/0/Blog/agile-1.jpg http://www.romanpichler.com/wp-content/uploads/2010/10/10TipsFeaturedImage.jpg

http://www.scrumdesk.com/pictures/Planning%20matrix.jpg


9 9

Primary Problem in Software Development

https://flic.kr/p/6fE1TN


10 10

Guess?

•  Software requirements is a communication problem.

•  People who want the software must communicate with those who will build it.


11 11

Requirements is a Communication Problem!

https://flic.kr/p/ehKDpk


12 12

Challenges

1.  Who defines requirements?

2.  How are they “discovered”?

http://www.officeclipart.com/office_clipart_images/document_being_search_by_a_magnifying_glass__search_icon_0515-1007-3003-0748_SMU.jpg


13 13

So Who Defines The Requirements?

…functionality and dates are mandated with little regard for reality

…done regardless of whether developers understand

…features are progressively dropped as the deadline nears

…lengthy upfront requirements negotiation and signoff

If the Business define them…


14

•  Assume everything is knowable in

advance •  Are time-consuming to write and

tedious to read •  Treat learning as a “Change of

Scope” •  Don’t lend themselves to iterative,

incremental delivery process

Requirements Documents?


15 15

So Who Defines The Requirements?

...technical jargon replaces the language of the business

…may define incomplete or wrong requirements

…may not have full understanding of the business vision and/or the target users

…may trade quality for additional features

…may only partially implement a feature

…may solely make decisions that should involve the business

If the Developers define them…


16 16

What is the Solution?

Business and technical teams collaborate on defining and elaborating the requirements.


17 17

User Stories

Extreme programming (XP) introduced the practice of expressing requirements in the form of user stories in the 1990’s.

So What Do We Do?


18 18

What is a User Story?

Short description of functionality–told from the perspective of a user

•  What does your user want? •  What value or benefit will they realize?


19 19

What is a User Story?

The basic user story template is simplistic, it helps us remember a need while providing context.

Image credit Lithespeed


20 20

Why Use Stories?

•  Comprehensible •  Developers and customers understand them •  People are better able to remember events if

they are organized into stories†

•  Right size for planning

•  Support and encourage iterative development

•  Can easily disaggregate closer to development time


21 21

What User Stories Are NOT

User Stories ≠ Requirements

User Stories ! Requirements

37

Context (Project Vision, Business Case, etc.)

User Story Conversation(s) Acceptance

Criteria

+ + Supporting Information

+

Common Understanding of a Need

Requirement

=

37

Requirements, More than Just a Story

Image credit Lithespeed


22 22

User Story Development

Comprised of three aspects:

1.  Written description of the story

2.  Conversations about the story that serve to flesh

out the details of the story

3.  Tests that convey and document details that can be

used to determine when a story is complete


23

•  Card!–!Stories!wri+en!on!note!cards!with!annota1ons!as!needed!(es1mates,!notes,!etc)!

•  Conversa*on!–!Details!behind!story!come!out!through!conversa1ons!with!the!Product!Owner!

•  Confirma*on!–!Acceptance!tests!confirm!the!story!was!coded!correctly!

Ron Jeffries 3 C’s


24

!•  User or customer need •  Product description •  Used for planning

Starting point to understand User Stories are a Conversation


25

•  User*!–!How!do!I!describe!what!I!want?!•  Stakeholder!–!What!do!I!need!in!my!product!to!be!

successful?!•  PM!–!How!do!I!track!and!schedule!this!work?!•  BA!–!What!are!the!details!of!this!feature?!•  UX!–!How!do!I!understand!the!users!needs?!•  Developer!–!What!are!the!details!of!the!tasks!I!

need!to!work!on!today?!•  QA!–!How!do!I!validate!this!completed!work?!

User Stories Facilitate Conversations


26 26

User Story Format

As a <user>,

I want to <take an action/accomplish a goal>

So that I <realize a benefit or value>

Description and Acceptance Criteria

Acceptance Criteria: 1.  Criteria A 2.  Criteria B 3.  Etc.


27

•  User!Interviews!– Select!right!interviewees!– Ask!openIended,!contextIfree!ques1ons!

•  Ques1onnaires!– Larger!popula1on!of!users!– When!you!need!specific!answers!to!ques1ons!

•  Observa1on!– Best!for!inIhouse!developments!

•  Story=wri*ng=workshops=

Gathering!User!Stories


28 28

Exercise

Let’s Write Some User Stories… http://www.iubenda.com/blog/wp-content/uploads/2010/10/Schermata-2010-10-24-a-18.24.46.png


29

Product Vision Statement

For Busy families with kids Who Want to go on a kid-friendly vacation Our ZappVacation Service

Is a web site that offers curated kid-friendly vacation choices

That Allows consumers to buy a “vacation package” that includes all travel arrangements

Unlike Existing travel sites that do not offer vacation packages for families with kids

Our product Provides a smooth way to plan a vacation by searching for and discovering new vacation destinations.


30

1.  Each!table!is!a!Scrum!Team!2.  Iden1fy!a!Product!Owner!3.  Iden1fy!a!Scrum!Master!4.  Each!team!member!individually!writes!user!stories!–!as!many!

as!they!can!or!want!to!!5.  Take!15!mins!to!write!stories!6.  Take!10!mins!to!review!them!all!7.  PO!selects!5!“best”!stories!8.  Put!your!5!best!user!stories!on!the!flip!chart!9.  Scrum!Master!facilitates!and!keeps!the!team!within!the!

allo+ed!1me!boxes.!

Instructions


31

Release Planning

https://www.versionone.com/agile-101/agile-project-management-customer-management-best-practices/agile-development-release-planning/


32

Acceptance=Criteria!–!Verifiable!and!testable!criteria!that!can!be!tested;!and!if!met!confirm!that!the!“ac1on”!can!be!successfully!performed.!I  These!are!essen1ally!tests!–!Condi1ons!of!sa1sfac1on!

I  Example:!As!a!user,!I!want!to!cancel=a=reserva*on.!I  Verify!that!a!premium!member!can!cancel!I  Verify!that!a!email!confirma1on!is!sent!

Acceptance Criteria


33

Acceptance=Criteria!–!Verifiable!and!testable!criteria!that!can!be!tested;!and!if!met!confirm!that!the!“ac1on”!can!be!successfully!performed.!I  These!are!essen1ally!tests!–!Condi1ons!of!sa1sfac1on!

I  Example:!As!a!Premium=Member,!I!want!to!cancel=a=reserva*on.!I  I=can=cancel=a=reserva*on.=I  I=receive=a=confirma*on=message=aFer=cancela*on=is=successful.=

I  I=receive=an=email=confirma*on=aFer=I=cancel=a=reserva*on.==

Acceptance Criteria Alternative Method


34 34

Exercise

Let’s Identify Acceptance Criteria…

http://manifesto.co.uk/wp-content/uploads/2014/08/user-stories-with-acceptance-criteria.png


35

1.   PO=selects=one=User=Story=from=the=5=“best”=stories!selected!in!the!previous!exercise.!

2.  Discuss!what!criteria!would!indicate!the!func1onality!was!constructed!correctly.!

3.  Write!the!criteria!on!the!flip!chart.!4.  Scrum!Master!facilitates!and!keeps!the!team!

within!the!allo+ed!1me!box.!

Instructions


36

Questions(


37

10311 Motor City Drive Suite 750 Bethesda, MD 20817

www.agilious.com

[email protected]

240.244.3311

www.facebook.com/agilious

@agilious

ADDRESS:

WEBSITE:

EMAIL:

TELEPHONE:

Our Contact Details

THANK YOU
