Agile training workshop

Boutique product development company
It is amazing what you can accomplish when you have a client-centric team to deliver outstanding products.

Syed Salman Ahmed, ACP | APM – Confiz Limited

1

Agile Training Workshop
Syed Salman Ahmed, ACP | Associate Project Manager

Workshop Agenda

• What is Agile
• Concepts of Agile:
–
–
–
–
–
–
–
–

Iteration
Daily Stand up
User Stories
Definition of Done
Planning
Review
Retrospective
Backlog Grooming

•
•
•
•

Scrum
XP
Kanban
Brief overview on use of JIRA


3

What is Agile?

• What do you think is the purpose of this workshop?
• Difference between how to agile and being agile?
• What advantages can you state of Agile?


5

Traditional vs. Agile Approach
TRADITIONAL

AGILE



Waterfall Approach



Iterative & Incremental



Need more time to market



Time boxed



Not all of the features are used by
consumers:



Focuses on Minimum Marketable
Features



Often/Always: 20%



Continuous involvement of Customer



Sometimes: 16%





Rarely/Never: 64%

Open to change requests at all stages
of life cycle


6

Agile Software Development
What is Agile Software Development?





Iterative and incremental development



Requirements and solutions evolve through collaboration



Teams are potentially self-organizing and cross-functional


7

Agile Manifesto

Individuals and interactions

Process and tools

Working software

over

Comprehensive documentation

Customer collaboration

over

Contract negotiation

Responding to change


over

over

Following a plan

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


8

Agile Manifesto
Individuals & Interactions over Processes & Tools




Each person can contribute unique value



Communication is clear, effective, quick and efficient



Stronger team work



Development teams can self-organize, be more innovative and customize the
processes as required



Team members take personal ownership of the project



Team members can have better job satisfaction


9

Agile Manifesto
Working Software over Comprehensive Documentation




Meeting done criteria – a measure of completion



Bare minimum documentation


10

Agile Manifesto
Customer Collaboration over Contract Negotiation




Make the customer part of the project on an ongoing basis



Develops a partnership between customer and development team



Customer gets the increment at the end of each iteration



Customer feedback is incorporated in regular intervals


11

Agile Manifesto
Responding to Change over Following a Plan




Responding quickly to customers, product users and market helps in developing
relevant and helpful products


12

Concepts of Agile

•
•
•
•
•
•
•
•

Iteration
Daily Standup
User Stories
Definition of Done
Planning
Review
Retrospective
Backlog Grooming & Estimation

14

Iteration


15

Iteration
•
•
•
•

Iterations are short time frames
Duration of an iteration is 1 – 4 weeks
Preference is 2 weeks
Potentially shippable product is ready at the end of an
iteration
• There can be more than one releases in an iteration, but not desirable
• There cannot be a release at the end of an iteration, again not desirable


16

Iteration (contd..)
• Most common misconception:
• All sprints are iterations, but all iterations are not sprints

• Ideal iteration ending date:
• An iteration should not end on a Friday


17

Daily Stand-up

• Daily Standup
• Questions of Daily Stand-up


18

Daily Stand-up







A maximum of 15 minute meeting of team members
Helps synchronize effort
Status is shared
Dependencies are resolved
Commitments are made
Problems are identified but NOT resolved


19

Questions of Daily Stand-up
 What has been done?
 What will be done before next meeting?
 What are any obstacles?


20

Punishments for non-attendees/late comers
•
•
•
•

Push-ups
Sit-ups
Hang a board the whole day “I came late”
Monitory fine

• Whatever team decides


21

User Stories

• Traditional Requirements
• User Story
• Epic and Theme


22

Traditional Requirements
Criteria to which the system or business should adhere
 Generated before the coding begins
 Often considered as constraints, conditions or capabilities of
the system
 Rarely contain acceptance criteria
 Contract between business and development



23

User Story
A product feature description written by Customer/Proxy from
the perspective of the end user.
 It helps team understand what work is to be done
 Customer/Proxy prioritizes and team estimates them
 It usually follows the format:


▪ As a : <Role>
▪ I want to : <Function>
▪ So that : <Desired Goal>


24

User Story (contd.)
Shifts the focus from writing about requirements to talking
about them
 Not a highly detailed document, rather a reminder for further
collaboration
 Atomic in nature
 Just-In-Time Tool
 A User Story should be End to End



25

User Story (contd.)


Follows the INVEST model:
▪ Independent

▪ Reduced dependencies, easy planning
▪ Negotiable

▪ Details are added via collaboration and not a contract
▪ Valuable

▪ Provides value to the customer
▪ Estimable

▪ Should not be big and vague/Team should be able to estimate
▪ Small

▪ Can be done in less than a week by the team
▪ Testable

▪ Has acceptance criteria

26

Epic and Theme





Theme is a collection of related stories
Epic is a large story that can be further divided into multiple
stories
For example, “A user can search for job” can be split into
multiple stories:
▪ Search by Location, Salary Range, etc.
▪ View Job Detail
▪ View Company Profile


27

Definition of Done




Definition of Done
Common Issues


28

Definition of Done
Done criteria
 Functional Testing by development team
 Customer specified scenarios
 Single User Story can have multiple acceptance tests
 Also used during regression testing
 DOD may not be added when an issue/task/story is created



29

Common Issues
Start from requirements documents in narrative format
 Too much information
• Missing information


• Team must understand the done criteria before committing to story

• Acceptance Criteria is confused with Test Cases


Acceptance Criteria: “How will I know when I am done with the story?”



Test Case: “How do I test and what are the test steps?”


30

Activity # 1
•
Create Stories
•

Create DOD

Planning





Sprint Goal
Planning Meeting
Estimation Technique – Planning Poker


32

Sprint Goal


A short statement of what the work will be focused on during
the sprint


33

planning meeting
Team
capacity

prioritization

•
Product
backlog
Business
conditions
Current
product

Technology

•

Analyze and evaluate
product backlog
Select sprint goal

Sprint
goal

planning

•
•
•

Decide how to achieve sprint
goal (design)
Create sprint backlog (tasks)
from product backlog items
(user stories / features)
Estimate sprint backlog in
hours


Sprint
backlog

34

Estimation Technique - Planning Poker


The size assigned is based on a fixed pool of numbers



Based on Fibonacci numbers


0 1 1 2 3 5 8 13 21 34 55 98

Adjusted sequence is:




0 ½ 1 2 3 5 8 13 20 40 100 α

Pre-requisite:




A standard story must be taken with size pre-allocated


35

Rules
Feature is read to the team with explanation by Product owner
 Item is discussed
 Each member rates it and places his vote face down
 All cards are turned over at same time
 If estimates are different, outliers are discussed
 Repeat until consensus is reached or group can “live with” a
selected size
 Use Kitchen time to limit discussions



36

5 finger rule


After round of discussion, if consensus is not reached at all, use this to move forward

1.
2.
3.
4.
5.


I am against this
I object and want to discuss
I have concerns but can live with it
I support with some reservations
I totally support it

Note: 1 or 2 require discussion and re-vote


37

Estimating at Start of Project
Lesser clarity of the entire project
 Try to get into as much detail as possible
 But not all details!!
 Plan for immediate release in complete detail only
 Rest of the details can be established as we go



38

Re-estimation
1. For tasks that were identified at high level at project
commencement


Create epics



Create multiple stories

2. Re-estimate story due to previous finding


Change only old story points



Change only new story points



Relatively change both old and new


39

Activity # 2
•

Lets estimate some stories!

Review


41

Review
Team presents what it accomplished during the sprint
 Typically takes the form of a demo of new features or underlying
architecture
 Informal




2-hour prep time rule



No slides

Whole team participates
 Invite the world



42

Retrospective


43

Retrospective


•
•
•
•

Periodically take a look at what is and is not working
Preferable to assign responsibility at the end of retrospective
Typically 30 minutes to an hour
Done after every sprint
Team/customer can participate


44

Backlog




Product Backlog
Sprint Backlog


45

Product Backlog
The requirements
 A list of all desired work on the project
 Ideally expressed such that each item has value to the users or
customers of the product
 Prioritized by the product owner
 Reprioritized at the start of each sprint



46

Sprint Backlog
Sprint Backlog is the identified list of items that the team will
work on in the current sprint/iteration
 Features in the Sprint Backlog will be exploded into User
Stories
 User Stories will be decomposed to individual tasks



47

Backlog Grooming & Estimation






Planning in general
An Agile Plan
Task Prioritization
Estimating Tasks


48

Planning in general



What is a good plan?
A plan helps answer questions


49

What is a good plan?
Reduce risk
 Reduce uncertainty
 Identify dependency
 Support better decision making
 Establish trust



50

A plan helps answer questions



When can I get feature “X”
When will the project be completed


51

An Agile Plan
Work as one team
 Work in short iterations
 Deliver something each iteration
 Focus on business priorities
 Inspect and adapt



52


53

Levels of Planning


54

Factors in Prioritization
Financial value of a feature
 Cost of development
 Learning curve
 Risk removed by developing a feature




Schedule Risk



Cost Risk



Functionality Risk


55

Task Prioritization

High Risk
Low Value

High Risk
High Value

Low Risk
Low Value

Low Risk
High Value

Risk

Value


56

Prioritizing Desirability
Must Haves
 The more the better
 Exciters


Techniques:




Kano model




Uses functional and dysfunctional questions

Relative weighing


57

Estimating Tasks









Estimating tasks
Paint Problem
Size of Story
Ideal days vs Actual days
Estimation Technique: Planning poker
Estimating at start of project
Re-estimation

58

Estimating Tasks
Unlike traditional project estimation




First estimate the size of a story



Then convert it into an estimate

List of desired
Features
Estimate
Size

Derive
Duration


Schedule

59

Estimate the time required to paint this map


60

Problems
Don’t know the size of rooms
 Don’t know details of the room
 Don’t know which paint to use
 Time to paint one room is unknown



61

Extending the problem


Based on the floor plan, you are supposed to determine how long will it
take you to paint a building that has a single floor 4 times the size of
given building and has 15 stories?


62

Sizing a Story
Determine the size of a story with respect to other stories






E.g. story A is twice the size of story b

This classification is normally termed as Story Points


63

Basic Concepts of Scrum

Overview of Scrum
 What is Scrum?
 Pillars of Scrum
 Roles
 Ceremonies/Events
 Artifacts
 Scrum of Scrums



65

An Overview of Scrum









Product Catalog
Sprint Backlog
Sprint
Daily Standup
Scrum Master
Potentially shippable to
the customer
Sprint Review
Retrospective meeting


66










A Product Owner creates a prioritized wish list called Product
Catalog
During Sprint Planning, the Scrum Team identifies and pulls a small
number of items from the Product Catalog, creating a Sprint Backlog
The Scrum Team then decides how to implement the items
The team has a timebox, called a Sprint, to complete its work
The team meets each day to assess the progress, Daily Standup
Scrum Master keeps the team focused on its goals
At the end of the sprint the work should be potentially shippable to
the customer
The sprint ends with a Sprint Review and Retrospective meeting


67



68

What is Scrum?
Scrum is an Agile Framework structured to support product
development
 Scrum consists of Scrum Teams and their associated:




Roles



Events



Artifacts



Rules


69

Transparency:




Share common standards and nomenclatures in Scrum Team

Inspection:




Detect undesirable variances through Scrum Events

Adaptation:




Make adjustments to the process and artifacts to minimize further deviation


70

Scrum Team
Product Owner
 Development Team
 Scrum Master



71

Product Owner
Customer/Proxy representing the stakeholders
 Responsible for maximizing the value of the product and the work of
Development Team
 Writes User Stories
 Sole person responsible to manage the Product Backlog




Clearly express the Product Backlog Items



Prioritize the items to achieve best goals and missions



Ensure the Product Backlog is transparent and visible to all



Ensures the Development Team understands the items in the Product Backlog


72

Team
Self-organizing team of size between 3 to 9
 Normally developers who turn Product Backlog into increments of
potentially shippable product based on “definition of done”
 Less than 3 members




Decrease the interaction



Result in smaller productivity



May encounter skill issues

More than 9 members




Require too much co-ordination


73

Team
Cross-functional team with all the skills necessary to create the
product increment as a team
 No titles for the team members other than “Developer”
 Each team member chips in and applies his/her expertise to all
the problems



74

Scrum Master
Ensures that Scrum rules are understood
 Ensures that Scrum rules are followed
 Resolves impediments
 Protects team from external interferences
 Removes the barriers between development and Product
Owner so that Product Owner derives the development
 Empowers the development team
 Improves engineering practices and tools so that each
increment is potentially shippable
 Keeps information on team’s progress up to date and ensures
its visibility



75

Servant Leadership
This kind of leadership includes:




Creating environment of personal safety where team members may both innovate
and come to friendly disagreements



Mentoring team members



Facilitating (not controlling) meetings



Guiding the team



Removing obstacles


76

Scrum Events
Sprint
 Sprint Planning Meeting
 Daily Scrum
 Sprint Review
 Sprint Retrospective



77

Scrum Artifacts


Product Backlog
Sprint Backlog



Increment – not that one! 




78

Scrum of Scrums (SOS)
For large project teams
 One person per team attends
 Frequency depends on need
 Time of meeting depends on need


Pre-requisite:




All teams must be synchronized at a product or portfolio level

A backlog must be maintained
 Must use a no name policy, instead use team name
 Like daily scrum problem resolution should be done after the meeting



79

Agenda of SOS
What has your team done since last meeting?
 What will your team do before next meeting?
 Is there any impediment for you?
 Will you be creating an impediment for others?



80

XP




Roles in XP
12 Practices of XP


82

Roles in XP
• Customer:
• Create and prioritizes stories.
• Can change release date by adding/ removing stories.

• Programmer:
• Estimates stories, usually works in pairs, and writes codes and tests.

• Coach:
• Is preferred but optional.
• Monitors processes and mentors and helps team.

• Tracker:
• Is preferred but optional.
• Monitors progress.
• A programmer can be a tracker in the same or in a different pair.


83

12 Practices of XP
1. Planning Games
2. Small Releases
3. Metaphor
4. Simple Design
5. Test-driven development
6. Refactoring
7. Pair Programming
8. Collective Ownership
9. Continuous Integration
10.40-Hours a Week
11.On-Site Customer
12.Coding Standards

84

12 Practices of XP (contd…)
1. Planning games:
To elicit requirements + to estimate

2. Small Releases:
Begin with smallest useful feature set

3. Metaphor/Product theme:
Provides easy to remember naming conventions

4. Simple design:
Just enough to get the job done

5. Test-driven development (TDD):
Write test before adding feature. If test runs, the job is done

6. Refactoring:
Rewrite code to improve internal design


85

12 Practices of XP (contd…)
7. Pair programming:
Work on same computer.
“Driver” writes code and “observer” or “navigator” reviews each line

8. Collective code ownership:
Anyone can change anywhere

9. Continuous integration:
At least once per day

10.Forty hour work week:
Overtime of more than a week is considered as a serious process failure

11.On site customer:
Continuous access is available

12.Coding standard:
Everyone follows them


86

Kanban Board

Feature to
develop

Tasks in queue

Tasks in
progress

Tasks
complete


Feature
complete

88


89

Using JIRA





Project Dashboard / System dashboard
Project Roadmap
Project Issues Summarization
Administration









Filters
Scrum Board







Versions
Issue Types
Workflows
Components (default assignees)
Roles

Plan
Work
Report
Filters on board

Issue Reporting


90

Thank you!

• Questions?


91

References

• www.mountaingoatsoftware.com
• http://ketiljensen.files.wordpress.com/2009/10/kanban_board_1.png
• http://en.wikipedia.org/wiki/Agile_software_development


92

Agile training workshop

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (20)

Semelhante a Agile training workshop

Semelhante a Agile training workshop (20)

Último

Último (20)

Agile training workshop