Agile training workshop

Syed Salman Ahmed, ACP | APM – Confiz Limited 1

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

Agile Training WorkshopSyed 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

What is Agile


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?


TRADITIONAL

Waterfall Approach

Need more time to market

Not all of the features are used by consumers:

Often/Always: 20% Sometimes: 16% Rarely/Never: 64%

AGILE

Iterative & Incremental

Time boxed

Focuses on Minimum Marketable Features

Continuous involvement of Customer

Open to change requests at all stages of life cycle

Traditional vs. Agile Approach


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


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

Process and toolsIndividuals and interactions over

Following a planResponding to change over

Comprehensive documentation

Working software over

Contract negotiationCustomer collaboration over

Agile Manifesto


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


Agile Manifesto

Working Software over Comprehensive Documentation Meeting done criteria – a measure of completion Bare minimum documentation


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


Agile Manifesto

Responding to Change over Following a Plan Responding quickly to customers, product users and market helps in developing

relevant and helpful products

Concepts of Agile


Concepts of Agile

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


Iteration


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


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


Daily Stand-up

• Daily Standup• Questions of Daily Stand-up


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


Questions of Daily Stand-up

What has been done? What will be done before next meeting? What are any obstacles?


Punishments for non-attendees/late comers

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

• Whatever team decides


User Stories

• Traditional Requirements• User Story• Epic and Theme


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


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>


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


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


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


Definition of Done Common Issues

Definition of Done


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


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?”

Activity # 1• Create Stories• Create DOD


Planning

Sprint Goal Planning Meeting Estimation Technique – Planning Poker


Sprint Goal

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


planning meeting

prioritization

• Analyze and evaluate product backlog

• Select 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

Sprintgoal

Sprintbacklog

Business condition

s

Team capacity

Product backlog

Technology

Current product


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


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


5 finger rule

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

1. I am against this2. I object and want to discuss3. I have concerns but can live with it4. I support with some reservations5. I totally support it

Note: 1 or 2 require discussion and re-vote


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


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

Activity # 2

• Lets estimate some stories!


Review


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


Retrospective


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


Backlog

Product Backlog Sprint Backlog


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


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


Planning in general An Agile Plan Task Prioritization Estimating Tasks

Backlog Grooming & Estimation


What is a good plan? A plan helps answer questions

Planning in general


What is a good plan?

Reduce risk Reduce uncertainty Identify dependency Support better decision making Establish trust


A plan helps answer questions

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


An Agile Plan

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


Levels of Planning


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


Task Prioritization

High RiskLow Value

High RiskHigh Value

Low RiskLow Value

Low RiskHigh Value

Risk

Value


Prioritizing Desirability

Must Haves The more the better Exciters

Techniques: Kano model

Uses functional and dysfunctional questions

Relative weighing


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


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


Estimate the time required to paint this map


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


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?


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

Sizing a Story


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

Basic Concepts of Scrum


An Overview of Scrum Product Catalog Sprint Backlog Sprint Daily Standup Scrum Master Potentially shippable to

the customer Sprint Review Retrospective meeting


An Overview of Scrum

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


An Overview of Scrum


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


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


Scrum Team

Product Owner Development Team Scrum Master


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


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

Team


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


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


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


Scrum Events

Sprint Sprint Planning Meeting Daily Scrum Sprint Review Sprint Retrospective


Scrum Artifacts

Product Backlog Sprint Backlog Increment – not that one!


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


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?

XP (Extreme Programming)


Roles in XP 12 Practices of XP

XP


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.


1. Planning Games2. Small Releases3. Metaphor4. Simple Design5. Test-driven development6. Refactoring7. Pair Programming8. Collective Ownership9. Continuous Integration10.40-Hours a Week11.On-Site Customer12.Coding Standards

12 Practices of XP


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


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

Kanban


Kanban Board

Feature to develop Tasks in

queue

Tasks in progress

Tasks complete

Feature complete


Using JIRA Project Dashboard / System dashboard Project Roadmap Project Issues Summarization Administration

Versions Issue Types Workflows Components (default assignees) Roles

Filters Scrum Board

Plan Work Report Filters on board

Issue Reporting


• Questions?

Thank you!


References

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

http://www.mountaingoatsoftware.com/

http://ketiljensen.files.wordpress.com/2009/10/kanban_board_1.png

http://en.wikipedia.org/wiki/Agile_software_development

Agile training workshop

Technology

Transcript of Agile training workshop