Agile SW Development with SCRUM http://tiny.cc/RcgcB Aniruddha Ray

Presumptions Audience is (well) aware of traditional SDLC methods Waterfall Model V Model Spiral Model Iterative Development (RUP) And concepts like: Requirements Traceability Use Cases Unit testing

Audience is (well) aware of traditional SDLC methods

Waterfall Model

V Model

Spiral Model

Iterative Development (RUP)

And concepts like:

Requirements Traceability

Use Cases

Unit testing

Introduction Learning Driven Continuous Team Communication Deliver in Short, Business-Focused Phases, Typically 2 – 3 Months Develop in End-to-End Functional Slices Continuously Integrate Code Throughout (Daily Builds) Fully-Automated, Continuous Testing at Both Functional and Unit Level Low Cost of Change Plan Driven Infrequent Team Communication Deliver Once in “Big Bang” Fashion, Typically 9 – 12 Months Develop in Layers: Presentation, Persistence, Business, etc. Integration of Different Layers Occurs at End of Build Phase Testing as Separate Phase at End of Project, Emphasizing Functional Level High Cost of Change Waterfall Agile Attempts to Nail Down Requirements Expects, accommodates Changes to Requirements

What is Agile ? Agile proponents believe Current software development processes are too heavyweight or cumbersome Too many things are done that are not directly related to software product being produced Current software development is too rigid Difficulty with incomplete or changing requirements Short development cycles (Internet applications) More active customer involvement needed CMM focuses on process Agile methods are considered Lightweight People-based rather than Plan-based Several agile methods No single agile method XP most popular in Development Scrum most popular in Project and Delivery Mgmt No single definition - Agile Manifesto closest to a definition Set of principles Developed by Agile Alliance

Agile proponents believe

Current software development processes are too heavyweight or cumbersome

Too many things are done that are not directly related to software product being produced

Current software development is too rigid

Difficulty with incomplete or changing requirements

Short development cycles (Internet applications)

More active customer involvement needed

CMM focuses on process

Agile methods are considered

Lightweight

People-based rather than Plan-based

Several agile methods

No single agile method

XP most popular in Development

Scrum most popular in Project and Delivery Mgmt

No single definition -

Agile Manifesto closest to a definition

Set of principles

Developed by Agile Alliance

Agile Manifesto A Statement of Values We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan While there is value in the items on the right, we value the items on the left more . Key signatories: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas http://www.agilemanifesto.org

A Statement of Values

We are uncovering better ways of developing software by doing it and helping others

do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

While there is value in the items on the right, we value the items on the left more .

Key signatories:

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas

http://www.agilemanifesto.org

Agile Principles We follow these principles: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

We follow these principles:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity--the art of maximizing the amount of work not done--is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

Agile Methods Scrum – Ken Schwaber and Jeff Sutherland Extreme Programming – Ron Jeffries and Kent Beck Adaptive Software Development (ASD) Dynamic System Development Method (DSDM) Lean Software Development – Mary Popendieck Kanban for SW (Scrumban???) Feature Driven Development (FDD) Crystal Framework – Alistair Cockburn IUP (and RUP done with Agile Principles) – IBM (Rational) Agile Modeling (Agile Data) – Scott Ambler

Scrum – Ken Schwaber and Jeff Sutherland

Extreme Programming – Ron Jeffries and Kent Beck

Adaptive Software Development (ASD)

Dynamic System Development Method (DSDM)

Lean Software Development – Mary Popendieck

Kanban for SW (Scrumban???)

Feature Driven Development (FDD)

Crystal Framework – Alistair Cockburn

IUP (and RUP done with Agile Principles) – IBM (Rational)

Agile Modeling (Agile Data) – Scott Ambler

Agile In Practice Focus on business value Work together closely as one team Work in short iterations Inspect and Adapt Remove waste ruthlessly (wasted effort, wasted time) Deliver working software early and often

Focus on business value

Work together closely as one team

Work in short iterations

Inspect and Adapt

Remove waste ruthlessly (wasted effort, wasted time)

Deliver working software early

and often

Scrum in 100 words Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time. It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month). – INSPECT and ADAPT The business sets the priorities. Our teams self-manage to determine the best way to deliver the highest priority features. At every ( pre-decided ) frequency (two weeks to a month) anyone can see real working software and (decide to release it as is or) continue to enhance for another iteration. The iterations (Sprints) are Time-Boxed .

Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time.

It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month). – INSPECT and ADAPT

The business sets the priorities. Our teams self-manage to determine the best way to deliver the highest priority features.

At every ( pre-decided ) frequency (two weeks to a month) anyone can see real working software and (decide to release it as is or) continue to enhance for another iteration.

The iterations (Sprints) are Time-Boxed .

A Short History of Scrum 1995: - Design of a new method: Scrum by Jeff Sutherland & Ken Schwaber - Enhancement of Scrum by Mike Beedle & combination of Scrum with Extreme Programming 1996: introduction of Scrum at OOPSLA conference 2001: publication “Agile Software Development with Scrum” by Ken Schwaber & Mike Beedle 2005: Scrum and XP were the most popular Agile frameworks implemented (a lot of times Hand in hand) 2009: Scrum is the single most popular Agile implementation. However with popularity there is criticism or frustration of failure in some cases (Scrum-But) Successful appliance of Scrum in over 100 companies (BT, Sun, GE, Yahoo, Google, Siemens, Valtech etc)

1995:

- Design of a new method: Scrum by Jeff Sutherland & Ken Schwaber

- Enhancement of Scrum by Mike Beedle & combination of Scrum with Extreme Programming

1996:

introduction of Scrum at OOPSLA conference

2001:

publication “Agile Software Development with Scrum” by

Ken Schwaber & Mike Beedle

2005:

Scrum and XP were the most popular Agile frameworks implemented

(a lot of times Hand in hand)

2009:

Scrum is the single most popular Agile implementation.

However with popularity there is criticism or frustration of failure in some cases (Scrum-But)

Successful appliance of Scrum in over 100 companies (BT, Sun, GE, Yahoo, Google, Siemens, Valtech etc)

The Power of Scrum More business value delivered sooner Better return-on-investment for projects Greater visibility – to team and customers (also – Management) Improved productivity – People, Process Less waste – Lean mindset Higher quality – Inspect and Adapt Frequently Stronger teams – focussed, decisive, self managing Better morale across the whole team - camaraderie Engineering processes improved significantly The critical features built at the quickest time at the minimal cost

More business value delivered sooner

Better return-on-investment for projects

Greater visibility – to team and customers (also – Management)

Improved productivity – People, Process

Less waste – Lean mindset

Higher quality – Inspect and Adapt Frequently

Stronger teams – focussed, decisive, self managing

Better morale across the whole team - camaraderie

Engineering processes improved significantly

The critical features built at the quickest time at the minimal cost

The Dangers of Scrum It’s hard! It requires significant change It makes all dysfunction visible Scrum doesn’t fix anything: the team has to do it You may see things you don’t want to see It demands honesty and transparency Bad products will be delivered sooner, and doomed projects will fail faster Partial adoption may be worse than none at all Be forewarned: many Scrum adoptions fail

It’s hard!

It requires significant change

It makes all dysfunction visible

Scrum doesn’t fix anything: the team has to do it

You may see things you don’t want to see

It demands honesty and transparency

Bad products will be delivered sooner, and

doomed projects will fail faster

Partial adoption may be worse than none at all

Be forewarned: many Scrum adoptions fail

Basic Characteristics “ Self-managing or self-organizing” teams – no decision from anyone else . Product progresses in a series of month-long “sprints” - Timeboxed Requirements are captured as features/stories in a “product backlog” – One version of truth Features are prioritized (by Business value or any other parameter) by single Owner At the end of every sprint team should demo a “ potentially shippable product ”. No specific engineering practices prescribed – team selects the necessary tools and practices (can select from other Agile FW) One of the many “agile” frameworks – TEAM takes best practices from others if they want BUT for the RIGHT reasons

“ Self-managing or self-organizing” teams – no decision from anyone else .

Product progresses in a series of month-long “sprints” - Timeboxed

Requirements are captured as features/stories in a “product backlog” – One version of truth

Features are prioritized (by Business value or any other parameter) by single Owner

At the end of every sprint team should demo a “ potentially shippable product ”.

No specific engineering practices prescribed – team selects the necessary tools and practices (can select from other Agile FW)

One of the many “agile” frameworks – TEAM takes best practices from others if they want BUT for the RIGHT reasons

“MUST HAVE” Characteristics Teams have a dedicated PO and SM SM is co-located with team Team have a Scrum/War room. Timeboxing of Sprints. Scope of Sprint Backlog can be changed ONLY by Team (not SM or PO or Management) Sprint Demo at the end of every sprint No one changed PBL except PO Team decides the scope of Sprints.

Teams have a dedicated PO and SM

SM is co-located with team

Team have a Scrum/War room.

Timeboxing of Sprints.

Scope of Sprint Backlog can be changed ONLY by Team (not SM or PO or Management)

Sprint Demo at the end of every sprint

No one changed PBL except PO

Team decides the scope of Sprints.

“GOOD to have” Characteristics Teams of sizes 5-7 Co-located teams and “war room” Tie up with engg specific from XP (Test Driven Development, Refactoring) Minimum Documentation (as per need) SM not the People Manager or Traditional Manager No management influence on team. Coaching from SM. PO co-located with Team

Teams of sizes 5-7

Co-located teams and “war room”

Tie up with engg specific from XP (Test Driven Development, Refactoring)

Minimum Documentation (as per need)

SM not the People Manager or Traditional Manager

No management influence on team. Coaching from SM.

PO co-located with Team

Scrum Framework Roles : Product Owner, ScrumMaster, Team Ceremonies : Sprint Planning, Sprint Review, Sprint Retrospective, & Daily Scrum Meeting Artifacts : Product Backlog, Sprint Backlog, Burndown Chart, Velocity Chart

Roles :

Product Owner, ScrumMaster, Team

Ceremonies :

Sprint Planning, Sprint Review, Sprint Retrospective, & Daily Scrum Meeting

Artifacts :

Product Backlog, Sprint Backlog, Burndown Chart, Velocity Chart

Product Owner Responsible for maximizing the project’s ROI Creates high-level vision (MRD or PRD???) Creates a prioritized list of features (the Product Backlog) – decides on parameter of prioritization Final decision-maker on the Product Backlog – one version of truth!! Evolves the Product Backlog from Sprint to Sprint Helps the team be effective, by removing waste (like impediments and distractions) and supporting the team’s Scrum practices and efforts to improve. Can interact with customers, management or others to refine product vision. Single point of reference for team on ANY product related issue.

Responsible for maximizing the project’s ROI

Creates high-level vision (MRD or PRD???)

Creates a prioritized list of features (the Product Backlog) – decides on parameter of prioritization

Final decision-maker on the Product Backlog – one version of truth!!

Evolves the Product Backlog from Sprint to Sprint

Helps the team be effective, by removing waste (like impediments and distractions) and supporting the team’s Scrum practices and efforts to improve.

Can interact with customers, management or others to refine product vision.

Single point of reference for team on ANY product related issue.

Scrum Master Serves the Team Helps the Team remove obstacles and problems (“blocks”) Facilitates interactions within the Team, and between the Team and Product Owner Protects the Team Protects the team from outside disruption or threats Coaches the Team Helps the Team and Product Owner improve the effectiveness of their practices Helps the Team and Product Owner face and resolve difficult or uncomfortable issues Guides the skilful use of Scrum Teaches Scrum to the Team, Product Owner, and company Ensures that all standard Scrum practices are followed Avoid having the team’s manager be ScrumMaster Try having full time ScrumMaster for best results

Serves the Team

Helps the Team remove obstacles and problems (“blocks”)

Facilitates interactions within the Team, and between the Team and Product Owner

Protects the Team

Protects the team from outside disruption or threats

Coaches the Team

Helps the Team and Product Owner improve the effectiveness of their practices

Helps the Team and Product Owner face and resolve difficult or uncomfortable issues

Guides the skilful use of Scrum

Teaches Scrum to the Team, Product Owner, and company

Ensures that all standard Scrum practices are followed

Avoid having the team’s manager be ScrumMaster

Try having full time ScrumMaster for best results

Scrum Team Typically 7 (+ or – 2) people Co-located 100% dedicated to sprint (minor exceptions – Sys-Admin etc) Cross-functional QA, Programmers, UI Designers, etc. Includes all the skills necessary to produce an increment of potentially shippable product Team takes on tasks based on skills, not just official “role” Teams are self-organizing and self managing What to do if a team self-organizes someone off the team?? Ideally, no titles but rarely a possibility Team decides how much to commit to in a sprint Team works together to manage and complete the work to achieve the goal Membership can change only between sprints

Typically 7 (+ or – 2) people

Co-located

100% dedicated to sprint (minor exceptions – Sys-Admin etc)

Cross-functional

QA, Programmers, UI Designers, etc.

Includes all the skills necessary to produce an increment of potentially shippable product

Team takes on tasks based on skills, not just official “role”

Teams are self-organizing and self managing

What to do if a team self-organizes someone off the team??

Ideally, no titles but rarely a possibility

Team decides how much to commit to in a sprint

Team works together to manage and complete the work to achieve the goal

Membership can change only between sprints

Ceremonies Project Kickoff Meeting Sprint Planning Meeting Product Backlog Refinement Meeting Sprint Review Meeting Daily Scrum (Scrum of Scrums) – for bigger teams Sprint Retrospective Meeting

Project Kickoff Meeting

Sprint Planning Meeting

Product Backlog Refinement Meeting

Sprint Review Meeting

Daily Scrum

(Scrum of Scrums) – for bigger teams

Sprint Retrospective Meeting

Project Kickoff Meeting A special form of Sprint Planning Meeting – Optional. Meeting before the begin of the Project – 1 day of effort. Team (or a smaller core) may go through the product vision and entire backlog at higher level Helps in understanding the big picture – reviewing priorities and identifying dependencies/assumptions. May result in first cut of High Level estimates or minor refinements/changes in PBL (only PO will do it)

A special form of Sprint Planning Meeting – Optional.

Meeting before the begin of the Project – 1 day of effort.

Team (or a smaller core) may go through the product vision and entire backlog at higher level

Helps in understanding the big picture – reviewing priorities and identifying dependencies/assumptions.

May result in first cut of High Level estimates or minor refinements/changes in PBL (only PO will do it)

Sprint Planning Meeting 1 st Part: Creating/Refining Product Backlog (Edits, Reprioritization) Determining the Sprint Goal. Participants: Product Owner, Scrum Master, Scrum Team 2 nd Part: Participants: Scrum Master, Scrum Team Creating Sprint Backlog Discussing, Noting details on each scoped feature Dependencies/Assumptions (P.O available on call for discussion) Note: ScrumMaster facilitates the meeting and protects the team from pressure

1 st Part:

Creating/Refining Product Backlog (Edits, Reprioritization)

Determining the Sprint Goal.

Participants: Product Owner, Scrum Master, Scrum Team

2 nd Part:

Participants: Scrum Master, Scrum Team

Creating Sprint Backlog

Discussing, Noting details on each scoped feature

Dependencies/Assumptions (P.O available on call for discussion)

Note: ScrumMaster facilitates the meeting and protects the team from pressure

Suggested Steps 1) Team calculates how much time it will have available during the Sprint 2) Team takes first item from Product Backlog and breaks it into tasks 3) Team estimates how long the tasks will take (take care of all planned activities, definition of DONE and buffer) 4) If there’s available time remaining, move to the next item on Product Backlog and repeat 1-3 5) Finalize the features which have clarity and estimates and decide on how many to be scoped for sprint. Spring Planning Meeting

Suggested Steps

1) Team calculates how much time it will have

available during the Sprint

2) Team takes first item from Product Backlog and breaks it into tasks

3) Team estimates how long the tasks will take (take care of all planned activities, definition of DONE and buffer)

4) If there’s available time remaining, move to the next item on Product Backlog and repeat 1-3

5) Finalize the features which have clarity and estimates and decide on how many to be scoped for sprint.

Spring Planning Meeting – Input Output Sprint Planning Meeting Sprint Backlog Product Owner Scrum Team Management (Opt) Customers (Opt) Sprint Goal Product Backlog Team Capabilities Business Conditions Technology Current Product

Sprints Scrum projects make progress in a series of “sprints” Analogous to XP iterations Target duration is pre decided. Scrum suggests 2 weeks to one month a constant duration leads to a better rhythm Once decided Sprint duration MUST not change Product is designed, coded, and tested during EACH sprint EACH sprint should end in a potentially shippable code. Scope DOESNOT change within a sprint. Team may decide to push unfinished items to next sprint. PO can decide to CANCEL a sprint midway and restart (in special cases)

Scrum projects make progress in a series of “sprints”

Analogous to XP iterations

Target duration is pre decided. Scrum suggests 2 weeks to one month

a constant duration leads to a better rhythm

Once decided Sprint duration MUST not change

Product is designed, coded, and tested during EACH sprint

EACH sprint should end in a potentially shippable code.

Scope DOESNOT change within a sprint.

Team may decide to push unfinished items to next sprint.

PO can decide to CANCEL a sprint midway and restart (in special cases)

What is A Sprint A 2 - 4 week long iteration , during which team increments the product functionality NO outside influence can interfere with the Scrum team during the Sprint Each Sprint begins with the Kickoff meeting Daily Scrum Meeting conducted throughout the sprint. Each Sprint ends with a sprint demo and retrospective. Sprint duration or scope is immutable (unless critical business change happens) Sometimes teams may have intermediate Sprint review meetings (to discuss/pre-plan items of next sprint if it helps )

A 2 - 4 week long iteration , during which team increments the product functionality

NO outside influence can interfere with the Scrum team during the Sprint

Each Sprint begins with the Kickoff meeting

Daily Scrum Meeting conducted throughout the sprint.

Each Sprint ends with a sprint demo and retrospective.

Sprint duration or scope is immutable (unless critical business change happens)

Sometimes teams may have intermediate Sprint review meetings (to discuss/pre-plan items of next sprint if it helps )

Sequential vs. Overlapping Dev. Requirements Design Code Test

Scrum Meeting Goal of the Scrum Meeting Keep team coordinated and up-to-date with each other Surface “blocks” or problems daily Key Parameters Daily (fixed time) 15-minutes or less (no more) Stand-up Not for problem solving Only SM and Team Three questions for everyone: What did you do yesterday What will you do today? What obstacles are in your way? “ Chickens” and “Pigs” – Only “Pigs” can talk Help avoid other unnecessary meetings No discussion until after meeting ends After meeting SM will help remove the blocks and find solutions to problems.

Goal of the Scrum Meeting

Keep team coordinated and up-to-date with each other

Surface “blocks” or problems daily

Key Parameters

Daily (fixed time)

15-minutes or less (no more)

Stand-up

Not for problem solving

Only SM and Team

Three questions for everyone:

What did you do yesterday

What will you do today?

What obstacles are in your way?

“ Chickens” and “Pigs” – Only “Pigs” can talk

Help avoid other unnecessary meetings

No discussion until after meeting ends

After meeting SM will help remove the blocks and find solutions to problems.

Scrum Meeting – What Is It (IS NOT) Is NOT a problem solving session Is NOT a way to collect information about WHO is behind the schedule Is a meeting in which team members make commitments to each other and to the Scrum Master Is a good way for a Scrum Master to know (Track?) the progress of the Team Is THE meeting for a Scrum Master to know what is blocking the Team.

Is NOT a problem solving session

Is NOT a way to collect information about WHO is behind the schedule

Is a meeting in which team members make commitments to each other and to the Scrum Master

Is a good way for a Scrum Master to know (Track?) the progress of the Team

Is THE meeting for a Scrum Master to know what is blocking the Team.

Scrum Meeting FUDs Why daily? “ How does a project get to be a year late?” “ One day at a time.” Fred Brooks, The Mythical Man-Month. What if all team members are not present WHY are they not present (root cause?) – Burn Out, Low Team Morale or Over Pressure? Can Scrum meetings be replaced by emailed status reports? No Entire team sees the whole picture every day Create peer pressure to do what you say you’ll do

Why daily?

“ How does a project get to be a year late?”

“ One day at a time.”

Fred Brooks, The Mythical Man-Month.

What if all team members are not present

WHY are they not present (root cause?) – Burn Out, Low Team Morale or Over Pressure?

Can Scrum meetings be replaced by emailed status reports?

No

Entire team sees the whole picture every day

Create peer pressure to do what you say you’ll do

Sprint Review Meeting Goal Get hands on with what’s been built Inspect the quality Come up with ideas for improvements See whether the commitment was completed Team presents what it accomplished during the sprint Typically takes the form of a Demo of new features ( No Powerpoint ) Informal 2-hour prep time rule 2 hour demo time Participants – EVERYONE Informal and Fun

Goal

Get hands on with what’s been built

Inspect the quality

Come up with ideas for improvements

See whether the commitment was completed

Team presents what it accomplished during the sprint

Typically takes the form of a Demo of new features

( No Powerpoint )

Informal

2-hour prep time rule

2 hour demo time

Participants – EVERYONE

Informal and Fun

Sprint Retrospective Meeting Goal Find ways to improve the team’s way of working in the next Sprint Participants: SM and Team only Product Owner and managers should join for part (but not all) of the Retrospective Team needs time to talk by itself Feedback within team and self correcting decisions – SM to check that there is no outside imposition. Three questions (optional 4 th ) Start - What are worth trying Stop – What are waste and should be stopped Continue – What went well Escalation/Risk List to Upper Mgmt Don’t skip ever (Critical for the first 5-6 sprints!!!)

Goal

Find ways to improve the team’s way of working in the next Sprint

Participants: SM and Team only

Product Owner and managers should join for part (but not all) of the Retrospective

Team needs time to talk by itself

Feedback within team and self correcting decisions – SM to check that there is no outside imposition.

Three questions (optional 4 th )

Start - What are worth trying

Stop – What are waste and should be stopped

Continue – What went well

Escalation/Risk List to Upper Mgmt

Don’t skip ever (Critical for the first 5-6 sprints!!!)

Product Backlog Refinement – Optional Optional Meeting – Worked well in some cases Goal: During the Sprint, plan to spend ~5% of your available time doing Product Backlog Refinement (also known as Product Backlog Grooming) Team and Product Owner sit down and look ahead at Product Backlog Items for upcoming Sprints Team asks questions and clarifies requirements for upcoming items Team suggests items to add to the Product Backlog Team starts to think about how they’re going to implement the items (at a high-level)

Optional Meeting – Worked well in some cases

Goal:

During the Sprint, plan to spend ~5% of your available time doing Product Backlog Refinement

(also known as Product Backlog Grooming)

Team and Product Owner sit down and look ahead at Product Backlog Items for upcoming Sprints

Team asks questions and clarifies requirements for upcoming items

Team suggests items to add to the Product Backlog

Team starts to think about how they’re going to implement the items (at a high-level)

Product Backlog A list of all desired work on the project Usually a combination of story-based work (“let user search and replace”) task-based work (“improve exception handling”) List is prioritized by the Product Owner Typically a Product Manager, Marketing, Internal Customer, etc.

A list of all desired work on the project

Usually a combination of

story-based work (“let user search and replace”)

task-based work (“improve exception handling”)

List is prioritized by the Product Owner

Typically a Product Manager, Marketing, Internal Customer, etc.

Product Backlog Requirements for a system, expressed as a prioritized list of Backlog Items Is managed and owned by a Product Owner PO Can use MOSCOW tool to prioritize. Can be a Spreadsheet (typically) or any other report Usually is created during the first Sprint Planning Meeting or Project Kickoff Meeting Should be changed/updated and re-prioritized before each Sprint Planning Meeting. Product Backlog will have all features (including non- functional requirements)

Requirements for a system, expressed as a prioritized list of Backlog Items

Is managed and owned by a Product Owner

PO Can use MOSCOW tool to prioritize.

Can be a Spreadsheet (typically) or any other report

Usually is created during the first Sprint Planning Meeting or Project Kickoff Meeting

Should be changed/updated and re-prioritized before each Sprint Planning Meeting.

Product Backlog will have all features (including non- functional requirements)

From Sprint Goal to Sprint Backlog Scrum team takes the Sprint Goal and decides what tasks are necessary Team self-organizes around how they’ll meet the Sprint Goal Manager doesn’t assign tasks to individuals Managers don’t make decisions for the team Sprint Backlog is created Estimates are done by the team (best practice: Wideband Modified Delphi method)

Scrum team takes the Sprint Goal and decides what tasks are necessary

Team self-organizes around how they’ll meet the Sprint Goal

Manager doesn’t assign tasks to individuals

Managers don’t make decisions for the team

Sprint Backlog is created

Estimates are done by the team (best practice: Wideband Modified Delphi method)

Sprint Backlog A subset of Product Backlog Items, which define the work for a Sprint Is created ONLY by Team members Each Item has it’s own status Should be updated every day No more than 300 tasks in the list If a task requires more than 16 hours, it should be broken down Team can add or subtract items from the list. Product Owner is not allowed to do it

A subset of Product Backlog Items, which define the work for a Sprint

Is created ONLY by Team members

Each Item has it’s own status

Should be updated every day

No more than 300 tasks in the list

If a task requires more than 16 hours, it should be broken down

Team can add or subtract items from the list. Product Owner is not allowed to do it

Sprint Backlog during the Sprint Changes Team adds new tasks whenever they need to in order to meet the Sprint Goal Team can remove unnecessary tasks But: Sprint Backlog can only be updated by the team Estimates are updated whenever there’s new information

Changes

Team adds new tasks whenever they need to in order to meet the Sprint Goal

Team can remove unnecessary tasks

But: Sprint Backlog can only be updated by the team

Estimates are updated whenever there’s new information

Scalability of Scrum A typical Scrum team is 6-10 people Jeff Sutherland - up to over 800 people "Scrum of Scrums" or what called "Meta-Scrum“ Frequency of meetings is based on the degree of coupling between packets

A typical Scrum team is 6-10 people

Jeff Sutherland - up to over 800 people

"Scrum of Scrums" or what called "Meta-Scrum“

Frequency of meetings is based on the degree of coupling between packets

Scalability of Scrum

Confused about Scrum? How much Documentation : Scrum doesnot specify. Team decides (whats best for the project) What are user stories : short, plain-language description of the feature, in terms of customer value What are 3 C’s : Card, Confirmation and Conversation. It’s a common model for requirements/story analysis. How do we estimate in scrum : Scrum doesn’t specify. Only suggestion is to have 2 level of estimates – high level at PBL (may be Points) and low level at Sprint BL (may be Hours). Also,ONLY the team decided on estimates. Do we really need to release every sprint – 2 common approach - Release every sprint and multi sprint release. Do what gives maximum business benefit How can team scope the sprint – Team is COMMITING to delivery. So they should scope (Note: They may over or under-commit in initial sprints but with the right spirit and coaching they should stabilize in 5/8 sprints. A disturbing trend would continuous under or overcommitment) Why should we track Velocity : The team needs to find a Self-sustaining pace and confidence in commitment. Velocity provides the trend to them. (Note: Velocity IS NOT for management to track)

How much Documentation : Scrum doesnot specify. Team decides (whats best for the project)

What are user stories : short, plain-language description of the feature, in terms of customer value

What are 3 C’s : Card, Confirmation and Conversation. It’s a common model for requirements/story analysis.

How do we estimate in scrum : Scrum doesn’t specify. Only suggestion is to have 2 level of estimates – high level at PBL (may be Points) and low level at Sprint BL (may be Hours). Also,ONLY the team decided on estimates.

Do we really need to release every sprint – 2 common approach - Release every sprint and multi sprint release. Do what gives maximum business benefit

How can team scope the sprint – Team is COMMITING to delivery. So they should scope (Note: They may over or under-commit in initial sprints but with the right spirit and coaching they should stabilize in 5/8 sprints. A disturbing trend would continuous under or overcommitment)

Why should we track Velocity : The team needs to find a Self-sustaining pace and confidence in commitment. Velocity provides the trend to them. (Note: Velocity IS NOT for management to track)

Scrum EXPOSES Organization Impediments Scrum Process People arrive late to daily scrum and do not support basic discipline Scrum meetings take too long – team is bred and considers the tie unproductive Scrum master dictates design decisions or micromanages Teams are too large for effective daily scrum and sprint planning Teams do not report task-remaining time for burn-down analysis People practices Individuals are interrupted and tasked to work outside the sprint Teams are isolated in cubicles and not in open scrum area Teams members are not accountable for personal sprint commitments Individuals are multiplexed across too many projects and teams. Product engineering practices Cross-functional resources for definition, design, implementation, and test are not present on the team Sprints do not fully implement and test potentially deployable increments of customer-valued features. Product owner is not easily available or not integral to team System integration is not forced at each sprint Product owner won’t split up massive product backlog items to fit within a sprint Team have ineffective resources for automating builds and integrations Features are loaded into sprints after sprint begins Organizational issues Software process organization enforce ineffective processes Management assumes fixed-price, fixed-time, fixed-functionality delivery posture Software test and/or system QA is separate organization and is not integrated with team Organization rewards individual rather than team behavior. Existing rules or software capitalization demand adherence to document-drive waterfall approaches Team cannot make small, organizational space ad expense decisions needed to do their jobs.

Scrum Process

People arrive late to daily scrum and do not support basic discipline

Scrum meetings take too long – team is bred and considers the tie unproductive

Scrum master dictates design decisions or micromanages

Teams are too large for effective daily scrum and sprint planning

Teams do not report task-remaining time for burn-down analysis

People practices

Individuals are interrupted and tasked to work outside the sprint

Teams are isolated in cubicles and not in open scrum area

Teams members are not accountable for personal sprint commitments

Individuals are multiplexed across too many projects and teams.

Product engineering practices

Cross-functional resources for definition, design, implementation, and test are not present on the team

Sprints do not fully implement and test potentially deployable increments of customer-valued features.

Product owner is not easily available or not integral to team

System integration is not forced at each sprint

Product owner won’t split up massive product backlog items to fit within a sprint

Team have ineffective resources for automating builds and integrations

Features are loaded into sprints after sprint begins

Organizational issues

Software process organization enforce ineffective processes

Management assumes fixed-price, fixed-time, fixed-functionality delivery posture

Software test and/or system QA is separate organization and is not integrated with team

Organization rewards individual rather than team behavior.

Existing rules or software capitalization demand adherence to document-drive waterfall approaches

Team cannot make small, organizational space ad expense decisions needed to do their jobs.

Thank You !!!

Thank You !!!

Sprint Burndown Chart Depicts the total Sprint Backlog hours remaining per day Shows the estimated amount of time to release Actually is not a straight line Can bump UP and DOWN Ideally should burn down to zero to the end of the Sprint

Depicts the total Sprint Backlog hours remaining per day

Shows the estimated amount of time to release

Actually is not a straight line

Can bump UP and DOWN

Ideally should burn down to zero to the end of the Sprint

Release Burndown and Product Burndown Release Burndown Will the release be done on right time? X-axis: sprints Y-axis: amount of hours remaining The estimated work remaining can also burn up Product Burndown Is a “big picture” view of project’s progress (all the releases)

Release Burndown

Will the release be done on right time?

X-axis: sprints

Y-axis: amount of hours remaining

The estimated work remaining can also burn up

Product Burndown

Is a “big picture” view of project’s progress (all the releases)

Scalability of Scrum

Does This Ring A Bell?

Agile SW Development – XP and RUP The Essence of XP – Extreme Programming Key characteristics of XP include A team of five to ten programmers, co-located with customer representation on site. Development with frequent builds and iterations, each of which is releasable and delivers incremental functionality. Requirements are specified as stories, each a chunk of new functionality the user requires. Programmer work in pairs, follow strict coding standards, and do their own unit testing. Requirements, architecture, and design emerge over the course of the project RUP – The Rational Unified Process - process framework from IBM (Rational) Key characteristics of RUP include (Modified to IUP) RUP provides a full lifecycle approach covering a series of product lifecycle phases called inception, elaboration, construction, and transition RUP provides a SW development method and a set of software engineering practices that cover the majority of SW development disciplines. RUP is iterative. Within each phase, the product undergoes multiple iterations; the nature of each is determined in part by the life cycle phase. RUP is incremental: Each iteration builds on the functionality of the prior iteration; the software application evolves in this fashion with the benefit of regular and continuous feedback.

The Essence of XP – Extreme Programming

Key characteristics of XP include

A team of five to ten programmers, co-located with customer representation on site.

Development with frequent builds and iterations, each of which is releasable and delivers incremental functionality.

Requirements are specified as stories, each a chunk of new functionality the user requires.

Programmer work in pairs, follow strict coding standards, and do their own unit testing.

Requirements, architecture, and design emerge over the course of the project

RUP – The Rational Unified Process - process framework from IBM (Rational)

Key characteristics of RUP include (Modified to IUP)

RUP provides a full lifecycle approach covering a series of product lifecycle phases called inception, elaboration, construction, and transition

RUP provides a SW development method and a set of software engineering practices that cover the majority of SW development disciplines.

RUP is iterative. Within each phase, the product undergoes multiple iterations; the nature of each is determined in part by the life cycle phase.

RUP is incremental: Each iteration builds on the functionality of the prior iteration; the software application evolves in this fashion with the benefit of regular and continuous feedback.

Agile SW Development – DSDM and Lean DSDM – Dynamic Systems Development Method Key characteristics of DSDM include Active user involvement The team is empowered to make decisions The focus is on frequent delivery of products Fitness for business purpose is the essential criterion for acceptance of deliverables Iterative and incremental development is necessary to converge on an accurate business solution. All changes during development are reversible Requirements are base-lined at a high level. Testing is integrated throughout the life cycle. Collaboration and cooperation between all stakeholders is essential Lean Software – a set of principles derived from a combination of Lean-manufacturing thinking. Key characteristics of Lean Software include Reduced work in process inventory – Reduced investment in elaborated requirements, documented designs Reduced Cycle time – Build all software in much smaller lots Cross-training and cell-based manufacturing – Increase cross-training with pair programming and shared code assets. Have developers write tests as part of their code Continuous Process Improvement – Continuous reflection and adaption

DSDM – Dynamic Systems Development Method

Key characteristics of DSDM include

Active user involvement

The team is empowered to make decisions

The focus is on frequent delivery of products

Fitness for business purpose is the essential criterion for acceptance of deliverables

Iterative and incremental development is necessary to converge on an accurate business solution.

All changes during development are reversible

Requirements are base-lined at a high level.

Testing is integrated throughout the life cycle.

Collaboration and cooperation between all stakeholders is essential

Lean Software – a set of principles derived from a combination of Lean-manufacturing thinking.

Key characteristics of Lean Software include

Reduced work in process inventory – Reduced investment in elaborated requirements, documented designs

Reduced Cycle time – Build all software in much smaller lots

Cross-training and cell-based manufacturing – Increase cross-training with pair programming and shared code assets. Have developers write tests as part of their code

Continuous Process Improvement – Continuous reflection and adaption