One day Course On Agile

AGILE AND SCRUM OVERVIEW

BY JAMES WHITEHEAD

AGILE INTRODUCTIONMORNING SESSION• OBJECTIVES• AGILE INTRODUCTION

• WHAT IS AGILE?• WHY USE AGILE?• WHAT CHANGES

EXERCISE: MAKING THE DELIVERYINTRODUCTION TO SCRUM

SCRUM FRAMEWORKSCRUM ROLES

AFTERNOON SESSION• INTRODUCTION TO EXTREME

PROGRAMMING• USER STORY INTRODUCTION

• WHAT ARE THEY?• KEY ELEMENTS

• ESTIMATING AND PLANNING• ESTIMATING TECHNIQUES• SPRINT PLANNING• RELEASE PLANNING• REPORTING

• EXERCISE: MAKING THE DELIVERY PART II• WRAP UP AND CLOSE

COURSE OBJECTIVES

To Introduce agile approaches and techniquesTo explore how agile delivery differs from traditional delivery techniquesTo introduce Scrum and Extreme Programming

YOUR OBJECTIVES

Capture on a post-it• Name• Role

Current level of understanding about agile on a scale of 1…10• 1 – Absolutly no knowledge• 10 – I am the Agile Guru

Come up with a name for your Team

Effective scrum teams – James Whitehead

WATERFALL APPROACH TO DELIVERY

EXERCISE: MAKING THE DELIVERY

20 Mins to deliver as many requirements as possible

Delivery approach will be waterfallGather Requirements – BAPlan – PMDesign – DesignerBuild FE – Development front endBuild BE – Development back endBuild Middleware – Development middlewareTest – TestersCustomer Testing - Me

DEBRIEF

In your teams discuss:

What worked well?What obstacles did you encounter?What bottlenecks appeared?What would you change and how would you change it?

Time: 15 MinutesCapture points on paper providedPresent back summary of discussion


AGILE INTRODUCTION

WHAT IS AGILEAgile is Agile Is Not

Scrum is Scrum Is Not

WHAT IS AGILE?

WHERE IT FITS IN THE WIDER PROJECT LANDSCAPE

AGILE MANIFESTO

CORE OF AGILE

• TIMELY, REGULAR AND RELIABLE DELIVERY OF BUSINESS VALUE THROUGH SHORT SPRINTS (ITERATIONS)

• DELIVERY OF THE HIGHEST PRIORITY FUNCTIONALITY THROUGH COLLABORATION OF THE PRODUCT OWNER AND THE DELIVERY TEAM

• CONTINUOUS PROCESS IMPROVEMENT THROUGH FEEDBACK

MAXIMISE VALUE THROUGHDISCIPLINE AND FEEDBACK

WHAT CHANGES?• BUSINESS PARTNERS AND THEREFORE THE BUSINESS HAVE CONTROL OVER

PRIORITIES THROUGH CONTINUOUS COLLABORATION• FASTER DELIVERY OF BUSINESS BENEFITS THROUGH ITERATIVE DELIVERY• REDUCED RISK THROUGH MORE FREQUENT AND EARLY DELIVERY• HIGHER QUALITY OF DELIVERABLES THROUGH CONTINUOUS TESTING• GREATER VISIBILITY AND MORE ACCURATE REPORTING THROUGH DELIVERY

OF WORKING PRODUCT• IMPROVED TEAMWORK AND MORALE THROUGH EMPOWERMENT AND SELF

ORGANISATION• ADAPTIVE PROCESS THROUGH CONTINUOUS LEARNING AND IMPROVEMENT• ENHANCED ABILITY TO CHANGE THROUGH ITERATIVE PLANNING AND

CONSTANT COMMUNICATION


INTRODUCTION TO SCRUM

WHAT IS SCRUM• SCRUM IS AN AGILE METHOD FOR PROJECT MANAGEMENT• TAKEUCHI AND NONAKA – “THE NEW NEW PRODUCT DEVELOPMENT

GAME” (HARVARD BUSINESS REVIEW JAN – FEB 1986)• FIRST IMPLEMENTED BY JEFF SUTHERLAND AT EASEL CORPORATION IN

1993• SCRUM PAPER BY KEN SCHWABER OOPSLA ‘95• 2001 AGILE MANIFESTO CREATED AND AGILE ALLIANCE FORMED• 2002 FIRST CSM COURSE• NOW OVER 90,000 CSMS (2012)• DECEPTIVELY SIMPLE• TURNS TEAMS INTO MANAGER OF THEIR OWN FATES

WHAT IS SCRUM?

• WHAT HAS SOFTWARE DELIVERY GOT TO DO WITH RUGBY?

STOP RUNNING THE RELAY RACE AND TAKE UP RUGBY!

• THE NEW NEW PRODUCT DEVELOPMENT GAME:• WATERFALL APPROACH: LIKE A RELAY RACE WITH ONE GROUP OF

FUNCTIONAL SPECIALISTS PASSING THE BATON TO THE NEXT GROUP.• HOLISTIC APPROACH (AGILE): LIKE A RUGBY TEAM PLAYING A GAME

WHERE THE “TEAM TRIES TO GO THE DISTANCE AS A UNIT, PASSING THE BALL BACK AND FORTH (WITHIN THE TEAM)”

DECEPTIVELY SIMPLE

Putting It into Practice in their context or environment…..

PredictiveAim Fire!

EmpiricalAim Fire Aim!

Vs

SCRUM VALUES

• EACH GROUP HAS BEEN GIVEN A VALUE.• COME UP WITH A PICTURE WHICH REPRESENTS THIS VALUE

SCRUM VALUES

Focus

Courage

SCRUM PRINCIPLES• WELCOME CHANGING REQUIREMENT EVEN LATE IN DEVELOPMENT• DELIVER VALUABLE WORKING PRODUCT FREQUENTLY. THIS IS OUR PRIMARY

MEASURE OF PROGRESS.• BUSINESS PEOPLE AND DELIVERY TEAM MUST WORK TOGETHER DAILY

THROUGHOUT THE PROJECT, AT A SUSTAINABLE PACE.• SIMPLICITY

• THE ART OF MAXIMISING THE AMOUNT OF WORK NOT DONE – IS ESSENTIAL• INSPECT AND ADAPT

• CONTINUOUS PROCESS IMPROVEMENT THROUGH FEEDBACK• SELF ORGANISING TEAMS

• BUILD PROJECTS AROUND MOTIVATED INDIVIDUALS. GIVE THEM THE ENVIRONMENT AND SUPPORT THEY NEED, AND TRUST THEM TO GET ON WITH THE JOB TO DELIVER.


SCRUM FRAMEWORK

SCRUM FRAMEWORK

CEREMONIES+

ARTEFACTS+

ROLES

SCRUM TEAM

• PRODUCT OWNER• SCRUM MASTER• TEAM MEMBER

SCRUM ESSENTIALS: PIG AND CHICKENS

• A SCRUM TEAM ONLY CONSISTS OF THE TEAM MEMBERS, PRODUCT OWNER, AND SCRUM MASTER.

• NOBODY ELSE IS ON THE TEAM.• THERE WILL BE OTHER “STAKEHOLDERS” OR “INTERESTED PARTIES”.

• THESE ARE CHICKENS NOT PIGS!

RESPONSIBILITIES OF A PRODUCT OWNERManages Stakeholders

and interests

Presents Product/Project View Accepts or rejects work

results

Works with scrum team in refining backlog

Prioritises work at project and sprint level

Works with business/customer to determine what will

make up project backlog

Is responsible for Return on Investment of project

Attends planning sessions, reviews and

daily scrums

SCRUM MASTER RESPONSIBILITIES• REMOVING THE BARRIERS BETWEEN DEVELOPMENT AND THE CUSTOMER SO THE

CUSTOMER DIRECTLY DRIVES DEVELOPMENT• TEACHING THE CUSTOMER HOW TO MAXIMISE ROI AND MEET THEIR OBJECTIVES IN

SCRUM• IMPROVING THE LIVES OF THE DEVELOPMENT TEAM BY FACILITATING CREATIVITY

AND EMPOWERMENT• IMPROVING THE PRODUCTIVITY OF THE DEVELOPMENT TEAM IN ANY WAY POSSIBLE• IMPROVING THE ENGINEERING PRACTICES AND TOOLS SO EACH INCREMENT OF

FUNCTIONALITY IS POTENTIALLY SHIPPABLE• GUARDIAN OF THE PROCESS• ENSURING QUALITY ISN’T COMPROMISED

• SERVANT LEADER & FACILITATOR

ASPECTS OF AN IDEAL SCRUM TEAM

• SELF ORGANISING• CROSS FUNCTIONAL WITH NO ROLES• SEVEN PLUS OR MINUS TWO• RESPONSIBLE FOR COMMITTING TO WORK• AUTHORITY TO DO WHATEVER IS NEEDED TO MEET THE SPRINT COMMITMENT• ONE PRODUCT OWNER WORKING AS PART OF THE TEAM• OPEN, COLLOCATED SPACE• EVERY MEMBER OF THE TEAM IS RESPONSIBLE FOR MANAGING THE TEAM• RESPECT AMONG TEAM MEMBERS

TEAM RESPONSIBILITIESDo whatever is needed to

meet the goals of the SprintWork Product

backlog in anticipation

of next sprint Ensure work

is delivered in priority

order

Take ownership of tasks in

sprint

Communicate with each other and

product owner

Break down Sprint work into tasks

Provide Estimates

RACI – CHART EXAMPLE Functiona

lManager(

s)

Scrum Master

Product Owner

Scrum Team

Project Manage

r

Ensure consistency of scrum practices across teams I C C I R/AProvide vision and goal for the product I I R/A I IProvide resource with right skills and mindset R/A I I C/I CPrioritise and manage the product backlog I F R/A C FRemove impediments R R R/A R RManage the implementation of the project plan I I C C R/AMake sure scrum practices are used and improved within the team RI R/A C R FCreate, apply and continuously improve the Definition of Done C F R R/A FOn time reporting to management I F R/A I FDefine acceptance criteria I F R/A C FWrite acceptance tests I F C R/A FEnsure quality of the product R R R/A R RManage Risks C C R/A C RApprove user stories (user stories meet the acceptance criteria) I F R/A C FDecide on release date and goal I I R/A I I

NOTE: 1. THE ABOVE RACI MATRIX DOESN’T COVER ALL THE ACTIVITIES

WITHIN THE SCRUM FRAMEWORK; THEREFORE ALWAYS CHECK THE RESPONSIBILITIES FOR EACH ROLE.

2. THE RACI MATRIX MAY DIFFER PER PROJECT DUE TO STRUCTURAL AND/OR ORGANIZATIONAL CONSTRAINTS.

CONSULTEDTHOSE WHOSE OPINIONS ARE SOUGHT, TYPICALLY SUBJECT MATTER EXPERTS; AND WITH WHOM THERE IS TWO-WAY COMMUNICATION.

INFORMEDTHOSE WHO ARE KEPT UP-TO-DATE ON PROGRESS, OFTEN ONLY ON COMPLETION OF THE TASK OR DELIVERABLE; AND WITH WHOM THERE IS JUST ONE-WAY COMMUNICATION.

FACILITATORHELPS TEAMS AND INDIVIDUALS TO CONTINUOUSLY IMPROVE AND UNDERSTAND THEIR ROLES WITHIN THE SCRUM FRAMEWORK. THEY HELP TEAM MEMBERS CHANGE THEIR BEHAVIOUR AND ACT AS A COACH AND A CHANGE AGENT.

RESPONSIBLETHOSE WHO DO THE WORK TO ACHIEVE THE TASK. THERE IS TYPICALLY ONE ROLE WITH A PARTICIPATION TYPE OF RESPONSIBLE, ALTHOUGH OTHERS CAN BE DELEGATED TO ASSIST IN THE WORK REQUIRED

ACCOUNTABLETHE ONE ULTIMATELY ANSWERABLE FOR THE CORRECT AND THOROUGH COMPLETION OF THE DELIVERABLE OR TASK, AND THE ONE FROM WHOM RESPONSIBLE IS DELEGATED THE WORK. IN OTHER WORDS, AN ACCOUNTABLE MUST SIGN OFF (APPROVE) ON WORK THAT RESPONSIBLE PROVIDES. THERE MUST BE ONLY ONE ACCOUNTABLE SPECIFIED FOR EACH TASK OR DELIVERABLE.

RECAP

• FOR THE ROLE YOU HAVE BEEN GIVEN FILL OUT THE FOLLOWING

Is Responsible For… Is not responsible for

Should have the following characteristics…..

Should not have the following characteristics……..

SCRUM CEREMONIES AND ARTEFACTS

VisionAim of the project with and owner

Vision ProductBacklog

SprintBacklog

Sprint Planning MeetingReview Product BacklogEstimate Sprint BacklogCommit to Timeframe

S P R I N T

30 days

24 hrs

Product Backlog Session

Daily Scrum MeetingDone since last timePlan for todayBarriers?

Sprint Review Meeting and Sprint RetrospectiveDemo features to all Retrospect on progress

Release Planning MeetingProduct BacklogPrioritised featuresDesired by customer

Burndown Chart

Potentially Deployable Increment

Backlog tasks expanded by the team

A VISION SHOULD ANSWER

• WHO IS THE CUSTOMER?• WHAT IS THE CUSTOMER’S PROBLEM?• HOW DOES THE PRODUCT SOLVE THE PROBLEM AND ADD VALUE?• WHAT ARE THE BENEFITS COMPARED TO OTHER SOLUTIONS THAT ARE

AVAILABLE TO THE CUSTOMER?• ON WHAT BASIS WILL THE CUSTOMER JUDGE THE PRODUCT?

PENNY BRIDGE VISION

• FOR ALL M1VIEW RESIDENTS• THE PENNY BRIDGE WILL PROVIDE A SAFE AND QUICK PEDESTRIAN

ACCESS TO THE CITY CENTRE• UNLIKE THE BLUE BRIDGE, PENNY BRIDGE:

• IS SAFE TO CROSS• IS BRIGHT AND ATTRACTIVE• WILL PAY FOR ITS OWN MAINTENANCE AND UPKEEP

SPRINT LENGTH: TIME BOXES

• SCRUM RECOMMENDS 30 DAYS• CAN BE DIFFERENT FROM (1W UP TO 6 WEEKS)• CONSIDER:

• HOW LONG THE BUSINESS CAN GO WITHOUT CHANGING IT’S MIND• PICK A LENGTH THAT SPREADS INTENSITY APPROPRIATELY• ABILITY TO RELIABLY PREDICT EFFORT ON TASKS FOUR WEEKS OUT• LENGTH OF THE OVERALL RELEASE• AMOUNT OF UNCERTAINTY ON THE PROJECT• THE OVERHEAD OF ITERATING

DAILY SCRUM ESSENTIALS• DAILY 15 MINUTE INFORMATION SHARING MEETING• SAME PLACE AND TIME EVERY DAY• STANDING UP, FACILITATED BY THE SCRUM MASTER• WHOLE SCRUM TEAM ATTENDS• THREE QUESTIONS

• WHAT HAVE YOU DON’T SINCE THE LAST MEETING THAT IS OF INTEREST TO THE TEAM?

• WHAT WILL YOU DO BEFORE THE NEXT MEETING THAT IS OF INTEREST TO THE TEAM?

• WHAT IS IN YOUR WAY?• IMPEDIMENTS• DECISIONS

DAILY SCRUM SMELLS

• PEOPLE WHO ARE NOT PART OF THE TEAM SPEAKING UP OR OUT OF TURN

• MISSING TEAM MEMBERS• SCRUMMASTER ASSIGNING WORK• DAILY SCRUM IS SEEN AS FOR THE SCRUM MASTER• REPEATING THE SAME TASKS• BACKLOG NOT UPTO DATE• BURNDOWN NOT THERE OR NOT GOING DOWN

SOME LAWS AND AGILE• Specifications will never be fully understood. Ziv’s Law

• The user will never know what they want until the system is in production (and maybe not even then).

Humphrey’s Law

• Software evolves more rapidly as it approaches chaotic regions.

Langdon’s Lemma

• An interactive system can never be fully specified or tested

Wegner’s Lemma

• Organisations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations

Conway’s Law


EXTREME PROGRAMMING

WHAT IS XP?

• EXTREME PROGRAMMING IS A DISCIPLE OF SOFTWARE DEVELOPMENT BASED ON VALUES OF SIMPLICITY COMMUNICATION, FEEDBACK AND COURAGE.

• IT WORKS BY BRINGING THE WHOLE TEAM TOGETHER IN THE PRESENCE OF SIMPLE PRACTICES, WITH ENOUGH FEEDBACK TO ENABLE THE TEAM TO SEE WHERE THEY ARE AND TO TUNE THE PRACTICES TO THEIR UNIQUE SITUATIONS.

VALUES, PRINCIPLES & PRACTICES

• VALUES ARE UNIVERSAL• PRACTICES ARE WAYS OF SOLVING THE COMMON DILEMMA WE ALL

ENCOUNTER IN SOFTWARE DEVELOPMENT• PRINCIPLES ARE THE BRIDGE BETWEEN THE TWO.

VALUES• COMMUNICATION

• MOTION WITHOUT COMMUNICATION IS NOT PROGRESS• SIMPLICITY

• WHAT IS THE SIMPLEST THING THAT COULD POSSIBLY WORK• FEEDBACK

• CHANGE IS INEVITABLE, CHANGE CREATE THE NEED FOR FEEDBACK• COURAGE

• EFFECTIVE ACTION IN THE FACE OF FEAR• RESPECT

• I AM IMPORTANT AND SO ARE YOU

PRINCIPLES

VALUES ARE TOO ABSTRACT TO DIRECTLY GUIDE BEHAVIOUR…..

LONG DOCUMENTS ARE INTENDED TO COMMUNICATE, SO ARE DAILY CONVERSATIONS.

WHICH IS THE MOST EFFECTIVE?

PRINCIPLES• HUMANITY

• IT’S ALL ABOUT PEOPLE!• ECONOMICS

• WE MUST PROVIDE BUSINESS VALUE• MUTUAL BENEFITS

• EVERY ACTIVITY SHOULD BENEFIT ALL CONCERNED• SELF-SIMILARITY

• THE STRUCTURE OF SOLUTIONS CAN BE COPIED INTO NEW CONTEXTS EVEN AT DIFFERENT LEVELS

• IMPROVEMENT• PERFECT IS A VERB NOT AN ADJECTIVE!

• DIVERSITY• WE NEED TO BRING TOGETHER A VARIETY OF

SKILLS, ATTITUDES AND PERSPECTIVES• REFLECTION

• GOOD TEAMS DON’T JUST DO THEIR WORK THEY THINK ABOUT HOW THEY ARE WORKING AND WHY THEY ARE WORKING

• FLOW• MOVE TOWARD A CONTINUOUS FLOW OF ACTIVITIES

RATHER THAN DISCRETE PHASES • OPPORTUNITY

• WE NEED TO LEARN TO SEE PROBLEMS AS OPPORTUNITIES FOR CHANGE!!!

• REDUNDANCY• THE CRITICAL, DIFFICULT PROBLEMS IN SOFTWARE

DEVELOPMENT SHOULD BE SOLVED IN SEVERAL DIFFERENT WAYS

• FAILURE• IF YOU’RE HAVING TROUBLE SUCCEEDING, FAIL FAST..

• QUALITY• SACRIFICING QUALITY IS NOT EFFECTIVE AS A MEANS OF

CONTROL• BABY STEPS

• MOMENTOUS CHANGE TAKEN ALL AT ONCE IS DANGEROUS• ACCEPTED RESPONSIBILITY

• IS SOMEONE TRIES TO GIVE YOU RESPONSIBILITY, ONLY YOU CAN DECIDE IF YOU ARE RESPONSIBLE OR IF YOU AREN’T

PRACTICES

• PRACTICES ARE SITUATION DEPENDENT• IF YOUR SITUATION CHANGES CHOOSE DIFFERENT PRACTICES TO MEET

THE SITUATION• HAVE A READ THROUGH THE TWO INNER CIRCLES PRACTICES AND THINK

ABOUT HOW COULD WE APPLY THESE TO OUR SIMULATION.

PRACTICES

PAIRING

• TWO BRAINS ARE BETTER THAN ONE• THE ABILITY TO BRAINSTORM SOLUTIONS AND REFINEMENT TO THE SYSTEM• CLARIFY IDEAS TOGETHER

• FOCUS – ABILITY TO KEEP EACH OTHER ON TRACK AND FOCUSED ON THE TASK• LOWER FRUSTRATION• ACCOUNTABILITY• ABILITY TO THINK AT TWO DIFFERENT LEVELS – SYNTACTICALLY AND BLUE-SKY• REDUCES UNNOTICED MISTAKES• KNOWLEDGE TRANSFER• REDUCES “HIT BY A BUS” SYNDROME• ALLOWS US ALL TO HAVE A TRULY RELAXING VACATION, OR RECOVERING SICK-TIME, WITHOUT GUILT

TESTING

• THERE ARE MANY LEVEL OF TESTING WITHIN BLACK-BOX AND WHITE BOX• ALL OF WHICH ARE VALUABLE AND IMPORTANT• LIKE MANY ENGLISH WORDS, WORDS FOR TESTING ARE ‘OVER

SUBSCRIBED’• RIGHT NOW, WE’RE FOCUSING ON TWO SPECIFICALLY AGILE FORM

FORMS OF TESTING• UNIT TESTING• ACCEPTANCE TESTING

UNIT TESTING

• TESTS A VERY SMALL UNIT OF CODE• TESTS THAT WILL SHOW THE DEVELOPERS THAT THEY HAVE

IMPLEMENTED THE PIECE OF CODE THEY WERE FOCUSED ON• WRITTEN BY THE DEVELOPER• WHITE-BOX

ACCEPTANCE TESTING

• TESTS THAT WILL SHOW THAT THE STORY CARD CAN BE ACCEPTED• THESE WILL OFTEN SPAN FUNCTIONALITY OF THE SYSTEM• PREFERABLY WRITTEN BY THE CUSTOMER (OR STORY WRITER)• BLACK-BOX• BUT SOMETIMES WRITTEN BY THE DEVELOPERS (THIS WHITE-BOX) ->

BABY STEPS• SELENIUM, JUNIT AND SQUISH ARE USED FOR AUTOMATED ACCEPTANCE

TESTING

UNIT TESTING

• WHAT DO WE TEST?• EVERYTHING THAT COULD BREAK• ANYTHING WE WANT TO REMEMBER• ANYTHING THAT LOOKS INTERESTING• ANYTHING THAT WE’VE FOUND A BUG IN

USE YOUR EXPERIENCE AND YOUR GUT FEELINGIF IN DOUBT WRITE MORE TESTSWE USE XUNIT TESTING FRAMEWORKS TO HELP US UNIT TESTXUNIT IS A CONVENTION WHERE X IS OFTEN REPLACED WITH A LETTER OR NAME THAT SYMBOLISES THE LANGUAGE I.E. JUNIT FOR JAVA, NUNIT FOR .NET, PYTHONUNIT FOR PYTHON(THIS CONVENTION ISN’T ALWAYS FOLLOWED THOUGH I.E. CACTUS IS FOR UNIT-TESTING SERVER-SIDE JAVA DOE)MOST OF THE XUNIT FRAMWORKS CAN BE FOUND AT: HTTP://RONJEFFRIES.COM/

TEST DRIVEN DEVELOPMENT

• PREVENTS SCOPE CREEP• ENSURES GOOD DESIGN• FOSTERS TRUST• CREATES RHYTHM (FLOW)

TEST DRIVEN DEVELOPMENT• PREVENTS SCOPE CREEP

• IT’S EASY TO GET CARRIED AWAY PROGRAMMING AND PUT IN CODE “JUST IN CASE”• BY STATING EXPLICITLY AND OBJECTIVELY WHAT THE PROGRAM IS SUPPOSED TO DO, YOU GIVE

YOURSELF A FOCUS FOR YOUR CODING• ENSURES GOOD DESIGN

• IF IT’S HARD TO WRITE A TEST, IT’S A SIGNAL THAT YOU HAVE A DESIGN PROBLEM, NOT A TESTING PROBLEM. LOOSELY COUPLED, HIGHLY COHESIVE CODE IS EASY TO TEST

• FOSTERS TRUST• IT’S HARD TO TRUST THE AUTHOR OF CODE THAT DOESN’T WORK. BY WRITING CLEAN CODE THAT

WORKS AND DEMONSTRATING YOUR INTENTIONS WITH AUTOMATED TEST, YOU FIVE YOUR TEAM MATES A REASON TO TRUST YOU

• CREATES RHYTHM (FLOW)• IT’S EASY TO GET LOST FOR HOURS WHEN YOU ARE CODING. WHEN PROGRAMMING TEST-FIRST, IT’S

CLEARER WHAT TO DO NEXT: EITHER WRITE ANOTHER TEST OR MAKE THE BROKEN TEST WORK.• SOON THIS DEVELOPS INTO A NATURAL AND EFFICIENT RHYTHM – TEST, CODE, REFACTOR, TEST,

CODE, REFACTOR

WHY TDD?• PROVIDES A SAFETY NET TO CHANGE• PROVIDES A WAY TO FAIL FAST• TESTING AND DEVELOPMENT PROCESS IS MORE COLLABORATIVE• BY WRITING OUR TEST FIRST WE CAN’T BE “TOO BUSY” TO WRITE TESTS

AFTER WE FINISH – IT’S FAR EASIER TO ADD THEM AS YOU GO.• BY WRITING OUR TESTS FIRST AND ONLY WRITING ENOUGH CODE TO

PASS THE TESTS WE ARE LESS LIKELY TO CODE THAT “MIGHT BE USEFUL LATER”

• WHEN WE CAN’T THINK OF ANY MORE TESTS WE’RE DONE• WE GET AN EVER GROWING SUITE OF REGRESSION TESTS AS THE

APPLICATION GROWS, GIVING US MORE CONFIDENCE IN THE APPLICATION

10 MINUTE BUILD

• AUTOMATICALLY BUILD THE SYSTEM AND RUN ALL THE TESTS IN 10 MINUTES

• 10 MINUTE BUILD IS THE IDEAL – WORK TOWARDS THIS• PRACTICES SHOULD LOWER STRESS – AN AUTOMATED BUILD LOWERS

STRESS CRUNCH TIME• ANT AND MAVEN ARE USED FOR BUILD

CONTINUOUS INTEGRATION• THE INTEGRATION STEP IS UNPREDICTABLE, BUT CAN EASILY TAKE MORE TIME THEN THE ORIGINAL

PROGRAMMING• THE LONGER YOU WAIT TO INTEGRATE, THE MORE IT COSTS AND THE MORE UNPREDICTABLE THE

COST BECOMES• INTEGRATE AND TEST CHANGES AFTER NO MORE THAN A COUPLE OF HOURS• THE MOST COMMON FORM OF CONTINUOUS INTEGRATION FOLLOWS THIS PATTERN:

• A PROGRAMMING PAIR CHECKS IN THEIR CHANGES• THE BUILD SYSTEM NOTICES THAT THE CODE HAS CHANGED• IT BUILDS THE SYSTEM• IT THEN RUNS ALL OF THE TESTS• IF THERE ARE PROBLEMS, THE BUILD SYSTEM NOTIFIES THE PROGRAMMING PAIR (BY EMAIL, TEXT MESSAGE,

GLOWING RED LAVA LAMP….)• THERE ARE MANY CONTINUOUS INTEGRATION TOOLS OUT THERE• SOME OF THE TOOLS USED ARE:

• JENKINS CI – HTTP://JENKINS-CI.ORG• COBERTURA – HTTP://COBERTURA.SOURCEFORGE.NET/

http://jenkins-ci.org/

http://cobertura.sourceforge.net/

CODE SMELLS

• CODE SMELLS• CODE SMELLS ARE NAME GIVEN TO “SUSPECT” DESIGN DECISIONS IN CODE• THEY USUALLY INDICATE CODE THAT IS OVERLY COMPLEX, DIFFICULT TO UNDERSTAND, AND/OR DIFFICULT TO

CHANGE• CODE SMELLS ARE NOT DEFINITELY AN ISSUE, BUT SHOULD BE INVESTIGATED

• EXAMPLES• DUPLICATED CODE• LARGE METHODS & CLASSES• DEAD CODE• COMPLEX LOGIC• POOR OR MISLEADING NAMES AND TERMS USED IN CODE

REFACTORING

• IF IT SMELLS, CHANGE IT!• REFACTORING IS THE SOLUTION TO CODE SMELLS• APPLIES SMALL CONTROLLED CHANGES TO A CODE BASE TO IMPROVE THE

DESIGN WHILE MAINTAIN THE BEHAVIOUR• REFACTOR TO MAKE IT EASY TO ADD NEW FEATURES• IT IS BEST SUPPORTED BY AUTOMATED TOOLS AND AUTOMATED TESTS.

MODERN DEVELOPMENT TOOLS ARE VITAL.• CRUCIAL CONTRIBUTOR OF RESILIENCE

SIMPLE DESIGN

• DO THE SIMPLEST THING THAT COULD POSSIBLY WORK• INVEST IN THE DESIGN OF THE SYSTEM EVERY DAY• XP TEAMS WORK HARD AT LOWERING THE COST OF CHANGE OVER TIME• NEED THE ABILITY TO ADAPT THE DESIGN TO FUTURE REQUIREMENTS• WITHOUT DAILY ATTENTION TO DESIGN THE COST OF CHANGES SKY-ROCKET AND RESULTS IN

POORLY DESIGNED, BRITTLE AND HARD-TO-CHANGE SYSTEMS• KEEP DESIGN INVESTMENT IN PROPORTION TO THE NEEDS OF THE SYSTEM SO FAR• INCREMENTAL DESIGN SUGGEST THE MOST EFFECTIVE TIME TO DESIGN IS IN THE LIGHT OF

EXPERIENCE• DESIGN DONE CLOSE TO WHEN IT USED IS MORE EFFECIENT


USER STORIES


USER STORIES

ELEMENTS OF A USER STORY• WHAT IS A USER STORY?

• A USER STORY DESCRIBES A SMALL PIECE OF SYSTEM FUNCTIONALITY, IN A SIMPLE AND EASY TO READ SENTENCE.

• A WELL WRITTEN USER STORY WILL DESCRIBE WHAT THE DESIRED FUNCTIONALITY IS, WHO IT IS FOR, AND WHY IT IS USEFUL.

• SOME PEOPLE ADOPT THE 5 W’S - WHO/WHAT/WHEN/WHERE/WHY IN LOOKING AT A USER STORY.

• THERE ARE 3 PARTS TO A FULLY FLESHED OUT USER STORY. IF YOU LIKE MARKETING-SPEAK, THEN YOU CAN CALL THEM THE “3 C’S”:

• THE CARD

• THE CONVERSATION

• THE CONFIRMATION

WHY USER STORIES• CONCISE AND TO THE POINT• ENCOURAGE COMMUNICATION AND COLLABORATION BETWEEN CUSTOMER

AND TEAM• STORIES REDUCE WASTE

• CREATED AS THEY ARE NEEDED• THEIR EVOLUTIONARY CREATION THEY REMAIN USEFUL AND RELEVANT

• DEFER DECISIONS• LAST RESPONSIBLE MOMENT• REVERSIBLE DECISIONS

• STORIES PROVIDE A FORM OF DOCUMENTATION• THEY FOCUS THE CUSTOMER AND THE TEAM TO THINK ABOUT AND

QUESTION BUSINESS VALUE

PICTURE THIS

• RED• 4 WHEELS• TOP OF THE RANGE TURBO ENGINE• STYLISH LOOKS

Subject to interpretation

THE CARDA TYPICAL USER STORY FOLLOWS THIS TEMPLATE:

“AS A [USER], I WANT [FUNCTION], SO THAT [VALUE]”

HAVING SUCH AN EASY TEMPLATE TO FOLLOW ALLOWS ANYONE INVOLVED WITH THE PROJECT TO HELP WRITE THEM, FROM SALES, TO DESIGNERS, DEVELOPERS AND TESTERS, ALL THE WAY THROUGH TO CLIENTS OR USERS.

WE REFER TO THIS AS “THE CARD” BECAUSE OFTEN THEY ARE WRITTEN ON 3X5 BITS OF PLAIN CARD, USUALLY TO GIVE A PHYSICAL CONSTRAINT WHICH LIMITS THE POSSIBLE LENGTH OF THE STORY.

HERE’S A FEW HYPOTHETICAL EXAMPLES WRITTEN FOR YOUTUBE. I’VE DEFINED A “CREATOR” AS SOMEONE WHO CONTRIBUTES VIDEOS TO THE SITE, AND “USER” AS SOMEONE WHO JUST WATCHES THEM:

As a course attendee I wantWriting Good Stories

Title Reserved for priorityPerspective

To know how to write good user stories so that I can submit cards to the planning game that are clear and will be accepted to the next sprint

Author Date Reserved for estimateBob 08/05/15

Conversation starterConversation starter

Reason

Requirements

WhyWhy

WhatWhat

WhoWhoGood short titleGood short title

AN EXAMPLE OF A SIMPLE CARD

As a course attendee I wantWriting Good Stories

Title Reserved for priorityPerspective

To know how to write good user stories so that I can submit cards to the planning game that are clear and will be accepted to the next sprint

Author Date Reserved for estimateBob 08/05/15

Conversation starterConversation starter

Reason

Requirements

WhyWhy

WhatWhat

WhoWhoGood short titleGood short title

THE CONVERSATIONTHINK OF THE CONVERSATION AS AN OPEN DIALOGUE BETWEEN EVERYONE WORKING ON THE PROJECT, AND THE CLIENT.

ANYONE CAN RAISE QUESTIONS, ASK FOR THINGS TO BE CLARIFIED, AND THE ANSWERS CAN BE RECORDED DOWN AS BULLET POINTS FOR LATER REFERENCE.

IT IS ALSO A STAGE WHERE YOU CAN RE-EVALUATE YOUR USER STORY, AND POSSIBLY SPLIT IT INTO MULTIPLE STORIES IF REQUIRED.

FOR EXAMPLE, WE DISCUSS THE CREATOR UPLOAD USER STORY, AND DECIDE THAT THERE ARE ACTUALLY MULTIPLE THINGS THAT CAN HAPPEN, SO WE SPLIT THEM, AND EXPAND ON THEM:

THE CONVERSATION CONT…AS A CREATOR, I WANT TO UPLOAD A VIDEO FROM MY LOCAL MACHINE SO THAT ANY USERS CAN VIEW IT.

• THE “UPLOAD” BUTTON WILL BE A PERSISTENT ITEM ON EVERY PAGE OF THE SITE.• VIDEOS MUST NOT BE LARGER THAN 100MB, OR MORE THAN 10 MINUTES LONG.• FILE FORMATS CAN INCLUDE .FLV, .MOV, .MP4, .AVI, AND .MPG.• UPLOAD PROGRESS WILL BE SHOWN IN REAL TIME.

AS A CREATOR, I WANT TO EDIT THE VIDEO’S METADATA WHILE A VIDEO IS UPLOADING, TO SAVE MYSELF TIME.

• EDITABLE FIELDS INCLUDE VIDEO NAME, DESCRIPTION, TAGS, AND PRIVACY SETTINGS.• ONCE SAVED, THE USER WILL BE TAKEN TO THEIR VIDEO’S DEDICATED PAGE.

ONCE YOU WRITE A FEW OF THESE AND GET INTO THE SWING OF IT, YOU’LL FIND YOU’RE GETTING A LOT OF DATA WRITTEN DOWN VERY QUICKLY.

BECAUSE OF THIS, IT’S IMPORTANT TO ORGANISE YOUR USER STORIES IN A MANAGEABLE WAY. I LIKE TO GROUP THEM BY INTERFACE, AND PRESENT THEM NEXT TO A WIREFRAME SHOWING THE INTENDED FUNCTIONALITY.

THE CONFIRMATIONTHE CONFIRMATION IS BASICALLY JUST A TEST CASE. IF YOU’RE NOT FAMILIAR WITH TEST PLANS AND TEST CASES, THINK OF A TEST CASE AS A SERIES OF STEPS THAT A USER MUST DO TO ACHIEVE THE USER STORY.

A TEST PLAN IS A COLLECTION OF TEST CASES.

WITH FULL COVERAGE OF YOUR SYSTEM IN YOUR TEST PLANS, YOU CAN EASILY TEST EVERY CORE PIECE OF FUNCTIONALITY AND TICK THEM OFF AS YOU GO THROUGH THEM.

A TEST CASE FOR OUR YOUTUBE EXAMPLE MIGHT LOOK LIKE -

THE CONFIRMATION CONT…AS A CREATOR, I WANT TO UPLOAD A VIDEO FROM MY LOCAL MACHINE SO THAT ANY USERS CAN VIEW IT.

1. CLICK THE “UPLOAD” BUTTON.2. SPECIFY A VIDEO FILE TO UPLOAD.

1. CHECK THAT .FLV, .MOV, .MP4, .AVI, AND .MPG EXTENSIONS ARE SUPPORTED.2. CHECK THAT OTHER FILETYPES AREN’T ABLE TO BE UPLOADED.3. CHECK THAT FILES LARGER THAN 100MB RESULTS IN AN ERROR.4. CHECK THAT MOVIES LONGER THAN 10 MINS RESULT IN AN ERROR.

3. CLICK “UPLOAD VIDEO”.4. CHECK THAT PROGRESS IS DISPLAYED IN REAL TIME.

USER STORY EXAMPLES "As a reader of this presentation, I want to understand how to write so I can be competent in putting them together

The visitor can enter a valid email to the subscribe form

The visitor cannot submit the form without entering a valid email

After submission, the visitor should see a "thank you" message on the top of the screen

BLOGUser Story..

"As a reader of a blog post, I want to subscribe to a newsletter so I can follow the blog"

Acceptance Criteria…

The visitor can enter a valid email to the subscribe form

The visitor cannot submit the form without entering a valid email

After submission, the visitor should see a "thank you" message on the top of the screen

LIBRARYAs a user of the library catalogue, I want advanced search options on the front page so that I can quickly and easily refine my search. I can limit the search by format/type.

I can delineate the search by date range.I can limit the search to publisher information such as title, author, subject, place, publisher and call number.I can restrict the search to a particular website/catalogue, collection.I can find advanced search options – advanced search options are carried through as filters to search results page.I can filter by availability.

SCENARIOStudents can purchase monthly parking passes online.Parking passes can be paid via credit cards.Parking passes can be paid via PayPal.Professors can input student marks.Students can obtain their current seminar schedule.Students can order official transcripts.Students can only enrol in seminars for which they have prerequisites.Transcripts will be available online via a standard browser.

PRODUCT BACKLOG

• A LIST OF USER STORIES FORM YOUR PRODUCT BACKLOG. OFTEN TERMED PBI (PRODUCT BACKLOG ITEM)

As a xxxxx I want xxx so that xxxx






ESTIMATE EACH ITEM (USER STORY)How long is this going to take?

- 1 day ?- 1 week?- Forever?

ESTIMATE EACH ITEMHow long is this going to take?

- 1 day ?- 1 week?- Forever?

Estimates are not time based but relative to each other

ESTIMATE EACH ITEM

• IS

• LIKELY TO TAKE LONGER THAN

• ?

• REMEMBER ESTIMATION IS RELATIVE SIZING!

#1

#2

2 – ESTIMATE EACH ITEMRELATIVE ESTIMATION

ESTIMATING STORY POINTS USING COMPLEXITY BUCKETS • THIS APPROACH PROVIDES A CONSISTENT WAY FOR TEAMS TO SIZE STORIES BY DISCUSSING EACH STORY

IN TERMS OF PRE-DEFINED BUCKETS OF COMPLEXITY BEFORE DECIDING ON THE FINAL POINTS. • THE STEPS ARE SIMPLE:

• DECIDE ON THE BUCKETS OF COMPLEXITY YOU THINK MATCH YOUR PROJECT. FOR EXAMPLE, MANY SOFTWARE DEVELOPMENT EFFORTS HAVE THE BUCKETS USED BELOW.

• DISCUSS THE STORY IN EACH BUCKET AND DETERMINE IF THE TEAM CAN AGREE IF THE WORK IT HAS A LIGHT, MEDIUM, HIGH OR COMPLEX LEVEL OF COMPLEXITY.

• ADD UP THE POINTS AND SEE WHICH FIBONACCI STORY POINT BUCKET IT FALLS INTO. IF IT FALLS BETWEEN TWO BUCKETS, HAVE THE TEAM DO A GUT CHECK AND DECIDE ON WHICH ONES IT FALLS INTO.

2 – ESTIMATION HELPFUL TIPSUser Interface Business Logic Data/Integration Testing

L = 1 L = 1 L = 1 L = 1M = 2 M = 2 M = 2 M = 2H = 3 H = 3 H = 3 H = 3C = 4 C = 4 C = 4 C = 4

Helpful Considerations

Helpful Considerations Helpful Considerations Helpful Considerations

- number of screen fields?

- number of business rules? - number of data stores - user testing complexity

- Screen validation logic?

- business rules complexity - complexity of Stored procedures/triggers

- data setup complexity for each test pack

- number of screens? - number of tables/relationships

- test automation complexity

1 2 3 5 8 13 21

ExampleAs a customer, I want to browse the list of products so that I view the details.

User interface: M = 2Business Logic: N/A

Data: L = 1Testing: L = 1

Total is 4 points, which is between 3 and 5, team decide on 3.

USER INTERFACE

• L = 1• M = 2• H = 3• C = 4• HELPFUL CONSIDERATIONS

• - NUMBER OF SCREEN FIELDS?• - SCREEN VALIDATION LOGIC?• - NUMBER OF SCREENS?

BUSINESS LOGIC


• - NUMBER OF BUSINESS RULES?• - BUSINESS RULES COMPLEXITY

DATA/INTEGRATION


• - NUMBER OF DATA STORES• - COMPLEXITY OF STORED PROCEDURES/TRIGGERS• - NUMBER OF TABLES/RELATIONSHIPS

TESTING


• - USER TESTING COMPLEXITY• - DATA SETUP COMPLEXITY FOR EACH TEST PACK• - TEST AUTOMATION COMPLEXITY

EXAMPLE

AS A CUSTOMER, I WANT TO BROWSE THE LIST OF PRODUCTS SO THAT I CAN VIEW THE DETAILS.

USER INTERFACE: M = 2BUSINESS LOGIC: N/ADATA: L = 1TESTING: L = 1

TOTAL IS 4 POINTS, WHICH IS BETWEEN 3 AND 5, TEAM DECIDE ON 3 BECAUSE THE BUSINESS LOGIC IS NOT APPLICABLE.

INVEST

Letter Meaning Description

I Independent The user story should be self-contained, in a way that there is no inherent dependency on another user story.

N Negotiable User stories, up until they are part of a sprint, can always be changed and rewritten.

V Valuable A user story must deliver value to the business

E Estimable You must always be able to estimate the size of a user story.

SSized appropriately or Small

User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.

T TestableThe user story or its related description must provide the necessary information to make testing of the development possible.

The INVEST mnemonic was created by Bill Wake as a reminder of the characteristics of a good quality user story, as may be used in a Scrum backlog.

INDEPENDENT

• THE USER STORY SHOULD BE SELF-CONTAINED, IN A WAY THAT THERE IS NO INHERENT DEPENDENCY ON ANOTHER USER STORY.

NEGOTIABLE

• USER STORIES, UP UNTIL THEY ARE PART OF A SPRINT, CAN ALWAYS BE CHANGED AND REWRITTEN.

VALUABLE

• A USER STORY MUST DELIVER VALUE TO THE BUSINESS

• VALUE CAN BE MONETARY• GAIN MORE CUSTOMERS• COMING UP WITH TECHNICAL STORIES THAT ARE REALLY FUN TO CODE BUT

BRING NO VALUE TO THE END-USER VIOLATES ONE OF THE AGILE PRINCIPLES, WHICH IS TO CONTINUOUSLY DELIVER VALUABLE SOFTWARE TO THE BUSINESS.

ESTIMABLE

• YOU MUST ALWAYS BE ABLE TO ESTIMATE THE SIZE OF A USER STORY.

• IF A USER STORY SIZE CANNOT BE ESTIMATED, IT WILL NEVER BE PLANNED, TASKED, AND, THUS, BECOME PART OF A SPRINT.

• SO THERE'S ACTUALLY NO POINT IN KEEPING THIS KIND OF USER STORY IN THE PRODUCT BACKLOG AT ALL.

TESTABLE

• THE USER STORY OR ITS RELATED DESCRIPTION MUST PROVIDE THE NECESSARY INFORMATION TO MAKE TESTING OF THE DEVELOPMENT POSSIBLE.

• REMEMBER HERE THESE TESTS CAN BE PART OF YOUR CONDITIONS OF SATISFACTION OR ACCEPTANCE CRITERIA.

SIZED APPROPRIATELY

• USER STORIES SHOULD NOT BE SO BIG AS TO BECOME IMPOSSIBLE TO PLAN/TASK/PRIORITIZE WITH A CERTAIN LEVEL OF CERTAINTY.

• TRY TO KEEP YOUR USER STORY SIZES TO TYPICALLY A FEW PERSON-DAYS AND AT MOST A FEW PERSON-WEEKS. ANYTHING BEYOND THAT RANGE SHOULD BE CONSIDERED TOO LARGE TO BE ESTIMATED WITH A GOOD LEVEL OF CERTAINTY OR EVEN "EPIC" AND BROKEN DOWN INTO SMALLER USER STORIES.

• THERE'S NO PROBLEM IN STARTING WITH EPIC STORIES, AS LONG AS THEY ARE BROKEN DOWN WHEN THE TIME TO PLACE THEM IN A SPRINT BACKLOG BECOMES CLOSER

OR SMALL

• TRY TO KEEP YOUR USER STORY SIZES TO TYPICALLY A FEW PERSON-DAYS AND AT MOST A FEW PERSON-WEEKS. ANYTHING BEYOND THAT RANGE SHOULD BE CONSIDERED TOO LARGE TO BE ESTIMATED WITH A GOOD LEVEL OF CERTAINTY OR EVEN "EPIC" AND BROKEN DOWN INTO SMALLER USER STORIES.

• THERE'S NO PROBLEM IN STARTING WITH EPIC STORIES, AS LONG AS THEY ARE BROKEN DOWN WHEN THE TIME TO PLACE THEM IN A SPRINT BACKLOG BECOMES CLOSER

MY USER STORY IS TOO BIG

• WHAT DO YOU DO IF THE ESTIMATION IS TOO BIG!!

THEMES

• THEMES MAY BE THOUGHT OF AS GROUPS OF RELATED STORIES. • OFTEN THE STORIES ALL CONTRIBUTE TO A COMMON GOAL OR ARE

RELATED IN SOME OBVIOUS WAY.• HOWEVER, WHILE SOME STORIES IN A THEME MAY BE DEPENDENT ON

ONE ANOTHER, THEY DO NOT NEED TO ENCAPSULATE A SPECIFIC WORK FLOW OR BE DELIVERED TOGETHER.

EXAMPLE THEMES

USER PORTALS (ACCOUNT SELF MANAGEMENT)INTEGRATIONREPORTINGMERCHANT HANDLING (ON AN ECOMMERCE SITE PAYMENT OF GOODS)CUSTOMER SERVICECONTENT MANAGEMENT SYSTEMS (CMS)

ARE ALL HIGH LEVEL THEMES FROM AN EPIC USER STORY ‘I WANT A WEBSITE TO SELL MY GOODS ONLINE’

ANOTHER EXAMPLE THEME..LET'S LOOK AT AN EXAMPLE OF A COMMON PIECE OF WORK THAT CAN OFTEN BE REPRESENTED AS A THEME – ‘PERFORMANCE TUNING’.

IMPROVING THE PERFORMANCE OF A SPECIFIC FEATURE OF AN APPLICATION OFTEN INVOLVES MAKING MANY SMALL IMPROVEMENTS TOWARD THE END GOAL OF A SIGNIFICANT PERFORMANCE IMPROVEMENT.

FOR EXAMPLE, IMAGINE THAT YOUR APPLICATION INCLUDES A REPORT TO DISPLAY THE TOTAL SALES NUMBERS PER SALESPERSON.

THESE NUMBERS MAY BE CALCULATED AS OF THE PREVIOUS DAY.

THIS CAN BE A TIME-CONSUMING REPORT TO EXECUTE, AND AS A RESULT THE ENTIRE APPLICATION TENDS TO HANG FOR SEVERAL SECONDS EACH TIME A USER RUNS IT.

THERE MAY BE SEVERAL THINGS WE CAN DO TO IMPROVE THIS REPORT, THINGS THAT ARE CAPTURED BELOW AS STORIES:

PERFORMANCE THEME

1. AS A SALESPERSON, I'D LIKE FOR THE UI OF THE APPLICATION TO REMAIN RESPONSIVE WHILE THE REPORT IS LOADING, SO I CAN CANCEL THE REPORT IF DESIRED.

2. AS A DEVELOPER, I'D LIKE TO PRE-AGGREGATE AND CACHE THE SALES NUMBERS AS OF THE PREVIOUS DAY, SO THEY DO NOT NEED TO BE RECALCULATED EACH TIME THE REPORT IS RUN.

3. AS A DEVELOPER, I'D LIKE TO GENERATE THE HTML TABLE CONTAINING THE SALES NUMBERS ON THE SERVER AND SEND IT PRE-RENDERED TO THE CLIENT, SO IT NO LONGER HAS TO BE RENDERED BY JAVASCRIPT ON THE CLIENT.

QUESTION

• WHO SPOTTED THE 3RD ONE ??

• THIS HAS NOTHING DO WITH PERFORMANCE BUT DID YOU SPOT IT?

PERFORMANCE THEME CONT..

EACH OF THESE STORIES HAS THE POTENTIAL TO IMPROVE THE PERFORMANCE OF THE REPORT.

HOWEVER, WHILE EACH STORY CONTRIBUTES TO THE SAME OVERARCHING GOAL, THEY DO NOT NEED TO BE COMPLETED IN A SPECIFIC ORDER.

FURTHERMORE, EACH STORY COULD BE DELIVERED INDEPENDENTLY FROM THE OTHERS AND STILL PROVIDE SOME MEASURABLE BENEFIT TO THE END USER.

FOR THESE REASONS, THESE STORIES ARE BEST GROUPED INTO A THEME RATHER THAN AN EPIC.

GROUPING THESE STORIES BY THEME ALLOWS US TO SEE THE BROADER GOAL THAT EACH STORY CONTRIBUTES TO WITHOUT FORCING US TO APPROACH THE STORIES IN A SPECIFIC ORDER.

ALSO, GROUPING THE STORIES AS A THEME ALSO NEGATES THE NEED TO HOLD DELIVERY OF THE ENTIRE GROUP UNTIL EACH STORY IS COMPLETE.

THIS GIVES US MORE FLEXIBILITY IN SCHEDULING AND PLANNING AS WELL AS IN OUR ABILITY TO ADD AND REMOVE STORIES AS THE SHAPE OF THE BACKLOG CHANGES.

WHAT IS AN EPIC

• EPICS RESEMBLE THEMES IN THE SENSE THAT THEY ARE MADE UP OF MULTIPLE STORIES.

• THEY MAY ALSO RESEMBLE STORIES IN THE SENSE THAT, AT FIRST, MANY APPEAR TO SIMPLY BE A "BIG STORY." AS OPPOSED TO THEMES, HOWEVER, THESE STORIES OFTEN COMPRISE A COMPLETE WORK FLOW FOR A USER.

• BUT THERE'S AN EVEN MORE IMPORTANT DIFFERENCE BETWEEN THEMES AND EPICS.

EPIC CONT…

• WHILE THE STORIES THAT COMPRISE AN EPIC MAY BE COMPLETED INDEPENDENTLY, THEIR BUSINESS VALUE ISN'T REALISED UNTIL THE ENTIRE EPIC IS COMPLETE.

• THIS MEANS THAT IT RARELY MAKES SENSE TO DELIVER AN EPIC UNTIL ALL OF THE UNDERLYING STORIES ARE COMPLETE.

• IN CONTRAST, WHILE STORIES COMPRISING A THEME ARE RELATED, EACH IS INDEPENDENT ENOUGH TO BE DELIVERED SEPARATELY AND STILL PROVIDE SOME MEASURABLE SENSE OF BUSINESS VALUE.

EXAMPLE OF A USER STORY(THIS IS AN EPIC)

• AS A DIRECTOR OF MARKETING, I WANT TO REVIEW THE PERFORMANCE OF HISTORICAL ADVERTISING CAMPAIGNS SO THAT I CAN IDENTIFY PROFITABLE CAMPAIGNS WORTH REPEATING.

INVESTINDEPENDENTTHE USER STORY SHOULD BE SELF-CONTAINED, IN A WAY THAT THERE IS NO INHERENT DEPENDENCY ON ANOTHER USER STORY.

NEGOTIABLEUSER STORIES, UP UNTIL THEY ARE PART OF A SPRINT, CAN ALWAYS BE CHANGED AND REWRITTEN.

VALUABLEA USER STORY MUST DELIVER VALUE TO THE BUSINESS

ESTIMABLEYOU MUST ALWAYS BE ABLE TO ESTIMATE THE SIZE OF A USER STORY.

SIZED APPROPRIATELY OR SMALLUSER STORIES SHOULD NOT BE SO BIG AS TO BECOME IMPOSSIBLE TO PLAN/TASK/PRIORITIZE WITH A CERTAIN LEVEL OF CERTAINTY.

TESTABLETHE USER STORY OR ITS RELATED DESCRIPTION MUST PROVIDE THE NECESSARY INFORMATION TO MAKE TEST DEVELOPMENT POSSIBLE.

INVEST

INDEPENDENTTHE USER STORY SHOULD BE SELF-CONTAINED, IN A WAY THAT THERE IS NO INHERENT DEPENDENCY ON ANOTHER USER STORY.

NEGOTIABLEUSER STORIES, UP UNTIL THEY ARE PART OF A SPRINT, CAN ALWAYS BE CHANGED AND REWRITTEN.

VALUABLEA USER STORY MUST DELIVER VALUE TO THE BUSINESS

ESTIMABLEYOU MUST ALWAYS BE ABLE TO ESTIMATE THE SIZE OF A USER STORY.

SIZED APPROPRIATELY OR SMALLUSER STORIES SHOULD NOT BE SO BIG AS TO BECOME IMPOSSIBLE TO PLAN/TASK/PRIORITIZE WITH A CERTAIN LEVEL OF CERTAINTY.

TESTABLETHE USER STORY OR ITS RELATED DESCRIPTION MUST PROVIDE THE NECESSARY INFORMATION TO MAKE TEST DEVELOPMENT POSSIBLE.

Has too many dependencies on other stories

You could negotiate on parts of the story

Clearly there is business value here avoids spending on campaigns and maximises investment in good campaigns

Can you really size this properly.

This story is very large and not small at all

There are so many test here on data and output to get testing into shape is complex and time consuming

EXAMPLE OF A USER STORY(STILL EPICS)

• AS A DIRECTOR OF MARKETING, I WANT TO SELECT THE TIMEFRAME TO USE WHEN REVIEWING THE PERFORMANCE OF PAST ADVERTISING CAMPAIGNS SO THAT I CAN IDENTIFY PROFITABLE ONES.

• AS A DIRECTOR OF MARKETING, I WANT TO SELECT WHICH TYPE OF CAMPAIGNS (DIRECT MAIL, TV, E-MAIL, RADIO AND SO ON) TO INCLUDE WHEN REVIEWING THE PERFORMANCE OF HISTORICAL ADVERTISING CAMPAIGNS.

EXAMPLE OF A USER STORY(THREE STORIES)

• AS A DIRECTOR OF MARKETING, I WANT TO SET SIMPLE DATE RANGES TO BE USED WHEN REVIEWING THE PERFORMANCE OF PAST ADVERTISING CAMPAIGNS SO THAT I CAN PICK AN EXACT SET OF DATES.

• AS A DIRECTOR OF MARKETING, I WANT TO SELECT SEASONS (SPRING, SUMMER, AUTUMN, WINTER) TO BE USED WHEN REVIEWING THE PERFORMANCE OF PAST ADVERTISING CAMPAIGNS SO THAT I CAN VIEW TRENDS ACROSS MULTIPLE YEARS.

• AS A DIRECTOR OF MARKETING, I WANT TO SELECT A HOLIDAY PERIOD (EASTER, CHRISTMAS AND SO ON) TO BE USED WHEN REVIEWING THE PERFORMANCE OF PAST ADVERTISING CAMPAIGNS SO THAT I CAN LOOK FOR TRENDS ACROSS MULTIPLE YEARS.

EXAMPLE OF A USER STORY3 STORIES OR ARE THEY CONDITIONS OF SATISFACTION (ACCEPTANCE CRITERIA)???

• SET SIMPLE DATE RANGES OF PAST ADVERTISING PERFORMANCE • PICK AN EXACT SET OF DATES.• SELECT SEASONS (SPRING, SUMMER, AUTUMN, WINTER) • VIEW TRENDS ACROSS MULTIPLE YEARS.• SELECT A HOLIDAY PERIOD (EASTER, CHRISTMAS AND SO ON)• REVIEW PERFORMANCE TRENDS ACROSS MULTIPLE YEARS.

SOME MORE TIPS ON SPLITTING USER STORIES

SPLITTING USER STORIES (CAN YOU SPLIT A STORY VERTICALLY LIKE A SLICE OF CAKE)

• 1. WORKFLOW STEPS• WHAT STEPS DOES A USER PERFORM?• ARE ALL STEPS NECESSARY (RIGHT NOW)?• CAN STEPS BE SIMPLIFIED (FOR NOW)?• I.E. STEPS IN AN ORDER PROCESS, LIKE

SELECTING A PAYMENT OPTION, DELIVERY METHOD.


• 2. BUSINESS RULES• WHAT RULES APPLY TO THIS STORY• ARE ALL BUSINESS RULES NECESSARY (RIGHT NOW)?• CAN SIMPLER RULES SUFFICE (FOR NOW)?• I.E. FAILURES DURING WEBSHOP ORDER PROCESS AND POSSIBLE

RECOVERY OPTIONS MAYBE DONE AS A LATER USER STORY.


• 3. HAPPY/UNHAPPY FLOW• WHAT DOES THE HAPPY/UNHAPPY FLOW LOOK LIKE?• ARE ALL UNHAPPY FLOWS NECESSARY (RIGHT NOW)?• CAN UNHAPPY FLOWS BE SIMPLIFIED (RIGHT NOW)?• I.E. FAILURES DURING WEBSHOP ORDER PROCESS AND

POSSIBLE RECOVERY OPTIONS


• 4. INPUT OPTIONS• WHICH PLATFORMS ARE SUPPORTED?• ARE ALL PLATFORMS REQUIRED (RIGHT NOW)?• ARE SOME PLATFORMS HARDER THAN OTHERS?• I.E. TABLET, IPHONE, DESKTOP, TOUCHSCREEN PC


• 5. DATATYPES AND PARAMETERS• WHAT DATATYPES ARE SUPPORTED?• WHAT PARAMETERS ARE RELEVANT?• I.E. DIFFERENT SEARCH OPTIONS/STRATEGIES OR

DIFFERENT KINDS OF REPORTS (TABLE, GRAPHS ETC)


• 6. OPERATIONS• WHAT OPERATIONS DOES THIS STORY ENTAIL?• ARE ALL OPERATIONS NECESSARY (RIGHT NOW)?• I.E. SPLITTING DOWN CRUD (CREATE, READ, UPDATE,

DELETE) OPERATIONS


• 7. TEST CASES/ ACCEPTANCE CRITERIA• WHAT TESTS ARE USED TO VERIFY THIS STORY?• WHAT ACCEPTANCE CRITERIA APPLY?• ARE ALL TEST SCENARIOS NECESSARY (RIGHT NOW)?• I.E. SOME TEST SCENARIOS MAY BE VERY COMPLEX AND NOT

HIGHLY RELEVANT TO THE CONTEXT OF THIS USER STORY.


• 8. ROLES• WHAT ROLES ARE INVOLVED IN THIS STORY?• ARE ROLES NECESSARY NOW?• I.E. CUSTOMER CAN CREATE ORDERS, ADMINISTRATION CAN

MANAGER ORDERS, PICKERS CAN PICK AND ORDER, PACKERS CAN PACK AND ORDER AND SHIPPING CAN SHIP THE ORDER.

ACCEPTANCE CRITERIAOR CONDITIONS OF SATISFACTION

CAPTURING ACCEPTANCE CRITERIA

• CAN BE WRITTEN AS ASSERTIONS• CAN BE WRITTEN AS QUESTIONS WITH EXPECTED OUTCOMES• CAN BE CAPTURED IN AUTOMATED TOOLS WITH EXPECTED INPUTS AND

OUTPUTS• CAN LINK OUT TO BUSINESS RULES, DATA DICTIONARIES FOR FURTHER

INFORMATION• CAN USE WHITEBOARD DIAGRAMS TO CAPTURE LOOK AND FEEL

CRITERIA OR PLACEMENT CRITERIA• CAN USE WIREFRAMES

GOOD ACCEPTABLE CRITERIA AND TESTS• S – SPECIFIC – EXPLICITLY DEFINED AND DEFINITE

• M – MEASUREABLE – POSSIBLE TO OBSERVE AND QUANTIFY

• A- ACHIEVABLE – CAPABLE OF EXISTING AND TAKING PLACE

• R – RELEVANT – HAVING A CONNECTION WITH THE STORY

• T – TIME-BOUND – WHEN WILL THE OUTCOME BE OBSERVED

SPECIFY BY EXAMPLE

Data Expected Result

Expected Message

Aa9ab$ Fail Too Short

AAbbCC11 Fail No Special Characters

$$$bbb111 Fail No Upper CaseAAA%% Fail No Lower CaseAAAA%%%%bbbbb Fail No numbers

IsThis$AGood11 Pass

THE USER STORY FLOWProduct Backlog

Release Backlog

Sprint Backlog

Might have an initial estimate (perhaps both analysis and

development and an expression of technical

and business confidence that this is real and achievable

As a __, I want to be able to __ so that __


More detailed estimate and a specific acceptance test – low confidence stories might be spiked or prototyped

I will know this is done when _____


I will know this is done when _____

To do this I must1) ______2) ______

Business Goal

Possible automation of the acceptance test

Development team breaks out the detail of work needed to pass test


PLANNING


VELOCITY

VELOCITY RANGES

1 2 3 4 5 6 7 8 905

1015202530354045

Velocity

Sprints

Last Observation = 42Mean = 38Mean (worst 3) = 35

RELEASE PLANNING

• RELEASE PLAN OF SPRINTS• SPRINT PLAN OF TASKS• BASED ON VELOCITY• PRODUCT BACKLOG – KEY ARTEFACT• TIMEBOXED• PRODUCT OWNER SETS PRIORITIES & ACCEPTANCE CRITERIA• TEAM SETS ESTIMATES AND DETERMINES CAPACITY

RELEASE PLANNING

• PRODUCT OWNER EXPLAINS VISION AND GOAL FOR RELEASE• PRODUCT OWNER EXPLAINS HIGHEST PRIORITY ITEMS (NOT IN-DEPTH)• TEAM ASKS QUESTIONS FOR CLARIFICATION• CONDITIONS OF SATISFACTION EXPLAINED (ACCEPTANCE CRITERIA)• DISCUSSION AROUND “WHAT IS DONE?”• RELATIVE ESTIMATE ARE PLACED ON THE ITEMS• TEAM DETERMINES WHAT STORIES GO INTO WHICH SPRINTS BASED ON THERE VELOCITY• TIMEBOXED MEETING• GIVE AN IDEA OF WHEN BACKLOG WILL BE DELIVERED OR HOW MUCH CAN BE DELIVERED IN THE

RELEASE

RELEASE PLANNING

• SHOWS WHAT WILL BE WORKED ON IN EACH SPRINT BASED ON SIZE ESTIMATES AND VELOCITY

Release Plan

Sprint 1• User

Story 1• User

Story 2

Sprint 2• User

Story 5• User

Story 3

Sprint 3-6

• User Story 4

• User Story 6

SPRINT PLANNING

• ALL OF THE SCRUM TEAM ATTEND• SCRUM MASTER FACILITATES THE SESSION• PRODUCT OWNER PRIORITISES AND CLARIFIES STORIES AND

ACCEPTANCE CRITERIA• TEAM MEMBERS BREAK DOWN STORIES INTO TASKS REQUIRED TO GET

THEM “DONE”• TEAM MEMBERS ESTIMATE THE TASKS IN HOURS• TEAM DETERMINE WHAT THEY CAN COMMIT TO DELIVERING IN THAT

SPRINT• TEAM MEMBERS SIGN UP TO THE INITIAL TASKS THEY WILL DO


SPRINT PLANNING MEETING

SPRINT PLANNING (IN TWO PARTS)

Product Backlog

Team Capabilities

Business Conditions

Retrospective

Previous Product

Increment

Part1

Part2

5% of the Sprint: Time Boxed

PO

TM

SM

Explain Goal, Vision &

Backlog Items

Design, Plan & Commit to

work

Facilitate &

Timebox

WHY

HOW

ALL

Next Sprint Goal

Product Backlog

Sprint Backlog

COMMITMENT BASED SPRINT PLANNING• TAKE (NEXT) HIGHEST PRIORITY STORY• SPLIT INTO TASKS• ESTIMATE TASKS IN HOURS• CAN YOU AS A TEAM TAKE ON THIS STORY IN THE NEXT SPRINT• IF YES GO BACK TO START• IF NO STOP• ASK THE TEAM TO SIGN UP FOR THE HIGHEST PRIORITY STORIES OR TASKS• NOT ALL STORIES OR TASKS NEED OWNERS AT THIS STAGE JUST ENOUGH

SO THAT EVERYONE KNOWS WHAT THEY WILL BE STARTING ON• HOW MANY STORY POINTS HAVE THE TEAM COMMITTED TO IN THIS

SPRINT?

SUMMARY

• STORIES WILL CHANGE• EVERYONE ESTIMATES• POINTS ARE NOT A UNIT OF TIME BUT RELATIVE• BEING CONSISTENT IS MORE IMPORTANT THAN BEING ACCURATE• ESTIMATES MUST INCLUDE UNCERTAINTY


SPRINT REVIEW (DEMO)


SPRINT REVIEW

• SHOW AND TELL WITH THE PRODUCT OWNER• TIME-OUT FOR THE TEAM TO REFLECT VIA A RETROSPECTIVE• REGULAR CHECKPOINT FOR THE PROJECT’S DIRECTION• FACILITATED BY THE SCRUM MASTER• “…THE LARGEST ROOM IN THE WORLD IS THE ROOM FOR

IMPROVEMENT…..”

SPRINT REVIEW

• DEMO TO PRODUCT OWNER, INTERESTED STAKEHOLDERS, REST OF TEAM WHAT HAS BEEN ACHIEVED THIS SPRINT

• EVERYONE GETS AN OPPORTUNITY TO SEE AND ASK QUESTIONS ABOUT WHAT HAS BEEN DELIVERED

• PRODUCT OWNER ACCEPTS OR REJECTS WORK• ANY CHANGES ARE CAPTURES AS NEW STORIES AND ADDED TO THE

BACKLOG

Show and Tell

WHAT IS RETROSPECTIVE?

• A RETROSPECTIVE IS THE TEAM/PROJECTS OPPORTUNITY TO:• STOP REFLECT AND LEARN• REFLECT ON WHAT HAS HAPPENED IN SPRINT OR RELEASE• IDENTIFY AND CELEBRATE WHAT IS WORKING• ACKNOWLEDGE WHAT WE HAVE LEARNED AND ACHIEVED• RECOGNISE AND LEARN FROM OUR MISTAKES• HEAR FROM OTHER PEOPLE INVOLVED THEIR PERCEPTION OF HOW

THINGS WENT

RETROSPECTIVE – PRIME DIRECTIVE

• TO SET THE PROPER MINDSET FOR ANY RETROSPECTIVE, IT IS HELPFUL TO REMIND THE TEAM OF NORM KERTH'S "PRIME DIRECTIVE:"

• "REGARDLESS OF WHAT WE DISCOVER, WE UNDERSTAND AND TRULY BELIEVE THAT EVERYONE DID THE BEST JOB THEY COULD, GIVEN WHAT THEY KNEW AT THE TIME, THEIR SKILLS AND ABILITIES, THE RESOURCES AVAILABLE, AND THE SITUATION AT HAND."

RETROSPECTIVES

• HTTPS://TRELLO.COM/B/B0PX6V4J/AGILE-COACHING

TRACKING AND REPORTING

BURNDOWN CHARTS

• TRACKS WORK REMAINING AGAINST THE ESTIMATED TOTAL• NOT EFFORT EXPENDED• BACKLOG UPDATED DAILY• CHART CAN BE PRODUCED AUTOMATICALLY• VERY SIMPLE GRAPH OF OUTSTANDING WORK V TIME LEFT• BIG VISIBLE CHARTS GOOD FOR FEEDBACK, REDUCING INTERRUPTIONS AND

SHOWING PROGRESS• NEED TO BE HONEST!

SPRINT BACKLOG & TOOLSExcel/Trello

Visual Studio Online


BURNDOWN CHARTS & CUMULATIVE FLOW

OTHER MEASURES OF PROGRESS

• THE TASK BOARD• CARDS WITH BIG GREEN TICKS• CARD MOVED FROM THE “TO-DO” TO “DONE” SIDE• GREEN BUILDS• RETROSPECTIVES• PRIMARY MEASURE IS THE WORKING PRODUCT• OPEN RISKS AND ISSUES POSTED VISIBLY ON WALL/WIKI

QUESTIONS

Technology

One day Course On Agile