Agile overview

Its all about the spirit of Agile & Scrum

Agile - OverviewAgile - Overview

By R Ragavendra Prasath

My identity

▪ R Ragavendra Prasath

▪ [email protected]

▪ Husband, Son, Friend, Student, Employee, Volunteer and Chocolate Enthusiast…!

Disclaimer

▪ All the slides given here are for information purposes only. Not for commercial.

▪ Created for the benefit of the Agile / Users as a contribution to the society.

What’s inside!▪ What is Agile….?

▪ Evolution of Agile

▪ Traditional Vs. Agile

▪ Why Agile…?

▪ Wastage of features

▪ Agile comes to rescue

▪ Agile Manifesto

▪ Agile Principles

▪ How Agile Projects Work

▪ Scrum – Overview

▪ Scrum contains…

What’s inside!▪ Release Planning

▪ Daily Scrum

▪ Sprint Planning

▪ Sprint Review

▪ Sprint Retrospective

▪ Some retrospective techniques

▪ Product Backlog

▪ Sprint Backlog

▪ Burn down Chart

▪ Roles @ Agile

▪ User Stories

What’s inside!▪ Estimation

▪ Story Points

▪ Velocity

▪ Task Board

▪ Shippable Functionality

▪ Definition of 'Done' (DOD)

▪ Process @ the floor

▪ Metrics

▪ Misconceptions about Agile

▪ Conclusion

▪ Bibliography

What is Agile….?

▪ Reflecting customer needs…

▪ a style of project management that focuses on

▪ Early delivery of business value

▪ Continuous improvement

▪ Scope flexibility

▪ Team input

▪ Delivering well tested products

Evolution of Agile▪ Believes that ‘software solutions evolve’ across iterations

▪ ‘Agile’ was christened in 2001

▪ All activities based on the ‘Agile Manifesto’

▪ Works on small packets of requirements called ‘sprints’

▪ Entire SDLC gets executed in each sprint

▪ Agile emphasizes ‘working software’ as primary measure of progress

▪ Agile is ‘adaptive’ against waterfall ‘predictive’ method

▪ Scrum project management is a popular, simple and loosely defined framework to execute agile projects

Traditional Vs. Agile

First Delivery Happens Here

First Delivery Happens Here

Traditional Vs. Agile

Waterfall Agile

Plan driven Learning driven

Infrequent client communication Continuous client communication

Deliver once in “Big Bang” fashion, Typically 6-9-12 months

Deliver is short, business focuses releases, typically in 2-3 weeks to 3 months

Requirements defined up front Just-in-time requirements

Develop in distinct phases with interim deliverables

Develop and deliver working code in 2-week long iterations

Testing as separate phase at end of project, typically emphasizing functional level

Fully-automated, continuous testing at both functional and unit level

High cost of change Low cost of change

Why Agile…?

▪ Change in requirements

▪ Lack of stakeholder involvement

▪ Early product realization issues

▪ Unrealistic schedule and inadequate testing

▪ Process as an overhead

▪ Wastage of features

▪ Cost of changeChallenges in IT industry

Wastage of features

▪ So, in Agile ‘Must-have’ features get built first, leaving nice to have features for later iterations.

Agile comes to rescue

▪ Validated product early

▪ Early ROI and lower costs

▪ Embracing change

▪ Customer and developer satisfaction

▪ Scope for innovation

Agile Manifesto

▪ 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 documentationCustomer collaboration over contract negotiation

Responding to change over following a plan

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

For People, Communication, Product & Flexibility

Agile Principles (shortened)

▪ First and foremost: Satisfy the customer - Deliver working, valuable software early and frequently

▪ Measure progress primarily by working software

▪ Have business people and developers work together daily

▪ Welcome changing requirements

▪ Create a self-organizing team of motivated individuals

▪ Communicate using face-to-face conversation

▪ Avoid nonessential work

▪ Maintain a sustainable pace of development

▪ Attend continuously to good design

▪ Retrospect and adjust regularly

For Customer Satisfaction, Quality, Teamwork & Project Management

Agile Principles

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

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

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

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

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

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

For Customer Satisfaction, Quality, Teamwork & Project Management

Agile Principles

7. Working software is the primary measure of progress.

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

9. Continuous attention to technical excellence and good design enhances agility.

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

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

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

For Customer Satisfaction, Quality, Teamwork & Project Management

How Agile Projects Work

▪ Transparency▪ Everyone involved on an agile project knows what is going on and

how the project is progressing.

▪ Frequent inspection▪ The people who are invested in the product and process the most

should regularly evaluate the product and process.

▪ Adaptation▪ Make adjustments quickly to minimize problems; if inspection shows

that you should change, then change immediately.

Transparent, Inspect, Adapt

Scrum - Overview

▪ Development in iterative, incremental manner - SPRINTS

▪ Time boxed

▪ Cross – Functional Teams (CFT)

▪ Self organizing team

▪ During sprint, no new items added

▪ Embraces change for next sprint

▪ Deliver the tangible / Potentially Shippable Product at the end of each sprint

▪ And say 'Done'

Scrum - Overview

Scrum contains…

▪ Meeting– Daily scrum

– Sprint Planning (Part 1 & Part 2)

– Sprint Review

– Retrospective

– Release Planning

▪ Roles– Product owner

– Scrum Master

– Team members (Developers & Testers)

▪ Artifacts– Product Backlog

– Sprint Backlog

– Burn down chart

▪ User stories– Estimation

– Velocity

– Story points

– Priority

– Potentially Shippable Product

– Task board

– Definition of 'Done'

Release Planning▪ Release is a group of usable product features that you release to production

▪ Establish the release goal

▪ Releases now go from a tentative plan to a more concrete goal

▪ Scrum team discusses risks to the release and how to mitigate those risks

▪ Need not include all the functionality outlined in the roadmap▪ should include at least the minimal marketable features

Daily Scrum

▪ Summary

– Update and coordination among team members

▪ Participants

– Development team, Scrum Master, Product Owner (optional)

▪ Duration, Do's & Don'ts

– 15 mins max.

– Around the story board ()

– Not a status meeting ()

To inspect the progress towards

sprint goal

▪ Goal

– What has been accomplished since last meeting?

– What will be done before next meeting?

– What obstacles are in the way?

Sprint Planning

▪ Summary– A meeting to prepare for the sprint,

typically divided into 2 parts

– (1. "What" 2. "How")

▪ Participants– Part 1:Development team, Scrum

Master, Product Owner (PO)

– Part 2: Development team, Scrum Master, Product Owner(optional)

▪ Duration, Do's & Don'ts– 1 hour / week of sprint

– Separate Part 1 and Part 2 meeting ()

– Each meeting not more than 2 hours max ()

What’s and How’s

▪ Goal

– Devise the ‘Sprint Goal’

– Prioritize, Analyze and Evaluate the product backlog

– Part 1 – understand 'What' PO wants and 'Why' are they needed

– Part 2 – focuses on 'How' to implement the items that the team decided to take on

Sprint Planning

▪ PO devises the Sprint Goal

▪ Velocity rate from previous sprints to guide how much to aim for

▪ Sprint back log created collaboratively

▪ Team can focus on 4 – 6 hours per day ▪ Rest of the time goes to email, meeting, lunch breaks, social

and coffee breaks

▪ Team select items from the product back log they can commit to completing

▪ High level design is considered and discussed within the teamEstimating the

speed

Sprint Review

▪ Summary

– Inspection and adaptation related to the product increment of functionality

▪ Participants

– Team members, Scrum Master, Product Owner + Customers, Users, Experts, Executives, Stakeholders and anyone else who is interested

▪ Duration, Do's & Don'ts

– 2 hours for 2 weeks sprint

– Anyone present is free to ask question and give input ()

– Not Demo ()

– No power point slides ()

Inspect and Adapt regarding the product

▪ Goal

– See and learn what is going on and then evolve based on feedback

i.e. PO to learn to what is going on with the product and Team and vice versa

– Review is an indepth conversation between Team and PO

– Hands-on inspection of the real software running live

Sprint Retrospective

▪ Summary– Discuss about the Results (Planned Vs Actual),

People, Team Composition and alignment, Communication, Collaboration, Processes of getting support, Tools, Productivity and etc

▪ Participants– Team members, Scrum Master, Product Owner

▪ Duration, Do's & Don'ts– 1.5 hours for 2 weeks sprint

– Use different techniques to gather information()

– Only focussing on problems ()

– Retrospectives are always conducted the same way()

Inspect and Adapt regarding the product

▪ Goal– What’s working?

– What's not working?

– What can we change?

– How to implement the change?

Some retrospective techniques

The Real Launch

DAKI – Drop, Add, Keep, Improve

Start, Stop, Continue, More of, Less of Wheel Complexity retrospective matrix

Thumbs Up, Thumbs Down,

News Ideas and Acknowledgement

Product backlog

▪ High level document for entire project

▪ Prioritized list of customer centric features as user stories

▪ Contains broad descriptions of all required features

▪ Contains rough development estimate and business value of the feature

▪ Includes new customer features, bugs, fixes, functions, engineering improvement goals, research work, and possibly known defects

▪ Product Owner owns product backlog who sets business value

▪ Development estimate is set by the team

Product backlog

Sprint backlog

▪ Contains information on how the team is going to implement features in upcoming sprint

▪ Features are broken down into tasks

▪ Tasks are never assigned, but picked up by team members

▪ Sprint backlog is the property of team

▪ Estimations are done by team

▪ A task board is used to update the status of tasks

Sprint backlog

Burndown Chart

Product Burn down

Sprint Burn down

Sprints Vs Story Points

Efforts Vs Days

Roles @ AgileProduct Owner Scrum Master Team

A customer representative / Understand customer and stakeholder needs

Servant Leader – to make the team fully functional and productive

Enjoys creating a product

Supplies project strategyUpholds scrum values and practices

Self organizing and self managing

Provides product expertiseRemoves roadblocks and prevents disruption

Cross functional

Manages and prioritizes product requirements

Fosters lose cooperation between external stakeholders and scrum team

Dedicated and collocated

Responsible for budget and profitability

Facilitates consensus building

Decides on release datesNot a manager / project manager

Accepts or rejects work

Decides what the product does and does not include

Responsibilities of the key players

User Stories▪ A simple description of a product requirement in terms of what that requirement must

accomplish for whom.

▪ It contains▪ Title: <a name for the user story>▪ As a <user or persona>▪ I want to <take this action>▪ So that <I get this benefit>

▪ The story should also include validation (Acceptance Criteria)▪ When I <take this action>, this happens <description of action>

▪ Also include▪ An ID▪ The value and effort estimate▪ The person who created the user story

▪ Must follow INVEST approach▪ Independent, Negotiable, Valuble, Estimable, Small, Testable

User Stories

Estimation

▪ Prioritize as High, Medium, Low or either 1 to 9.

▪ Features in the backlog.

▪ User stories are given Story Points.

▪ Use Poker Planning

▪ No of working hours available = no of team members x 7 hrs x 9 days

▪ Why 9 days: half of day is taken up with planning, half of day ten is taken up with sprint review and retrospective

▪ Why 7 hours : 7 productive hours

Don’t estimate too far into the future, if the future is unclear

Story Points

▪ Small and simple tasks are one point tasks, slightly larger/more complex tasks are two point tasks, and so on

▪ Points are calculated based on Fibonacci numbers

▪ Points are kind of like t‐shirt sizes▪ Extra-small - 1 pt▪ Small – 2 pts▪ Medium – 3 pts▪ Large – 5 pts▪ Extra-large – 8 pts▪ Epic user story that is too large to come into the sprint

Velocity

▪ Adds up the number of story points associated with the requirements for each sprint

▪ After the first few iterations, you’ll start to see a trend and will be able to calculate the average velocity

▪ The total number of completed story points is the team’s velocity, or work output

▪ Iteration 1 = 15 points▪ Iteration 2 = 19 points▪ Iteration 3 = 21 points▪ Iteration 4 = 25 points

▪ Average = 80 / 4 = 20

Task Board

▪ A task board provides a quick, easy view of the items within the sprint that the development team is working on and has completed

▪ Allow PO to move user stories to the Done to prevent misunderstandings about user story status

Kanban which means Visual Signal

Shippable Functionality▪ Deliver shippable functionality of the product to customer / user

▪ 3 major activities involved to shippable functionality ▪ Elaborating▪ Developing▪ Verifying

▪ Elaborating: ▪ the process of determining the details of a product feature▪ Ensure unanswered questions about a user story are answered

– so that the process of development can proceed.

▪ Developing▪ PO continues to work with the development team▪ Scrum Master protects from outside distractions and removes

impediements

▪ Verify▪ Automated Testing, Peer Reviews and Product Owner review

Shippable Functionality▪ Verify

▪ Automated Testing, – Unit testing– System testing

▪ Peer Reviews – Code review with other team member

▪ Product Owner review– After development and testing, team member moves the stories 'Done'– Product owner then reviews the functionality and verifies that it meets

the goals of the user story acceptance criteria

Definition of 'Done' (DOD)

▪ PO and Team need to agree on the definition of 'Done' for the sprint

▪ A subset of activities needed for creating Potentially Shippable

▪ Based on the existing capabilities

▪ DOD to be as close as possible to the Potentially Shippable

Consider each part of the definition of done — developed, integrated, tested, and documented — when you create estimates

Process @ the floorPhase Inputs Tasks Responsibility Outputs

Pre-Sprint  

Scope Document or Requirements from

Customer/PMG/

Finalize the scope of the Delivery/project

Customer or Business Analyst or

Product

Management or Sales

SoW document for Customization

Marketing/Sales

 Decide on the solution design or

solution architecture  

PRD for Roadmap

SoW document for Customization/PRD for

Roadmap 

• Study the end to end document and any other inputs received from the customer/end user and develop

user stories

•Write acceptance criteria for the user stories Product Backlog review

BA/PMG

Approved Product Backlog in terms of User

stories along with acceptance criteria

Iteration/Sprint 0

Product Backlog in terms of User stories along with

acceptance criteria

Backlog PrioritizationUnderstanding User Story in Details

by PU

Inital Estimate

PMG/PUBD,Engineering

Manager

Product Backlog with Priority and Iteration

Tagging

Initial Estimates

Process @ the floorPhase Inputs Tasks Responsibility Outputs

Iteration1 

Product Backlog with Priority and Iteration

Tagging

Sprint Planning Meeting is done.User Story tagged to Iteration

discussed.

Size and Effort Estimation done

Scrum Team

Sprint Backlog

Updated Product Backlog

Sprint Backlog

Sprint Execution1. Approach Note/Design document2. Coding with Code review records3. Automated Unit Testing or test

coverage report or 4. Unit test review and execution

results5. Testable Build with CM tagged

6. Defect Logging & Closure7. SIT Test Review and Execution

Results8. Release Build with CM tagged

Scrum TeamShippable Tested Release

Release Note Testing release

Metrics

▪ No. of user stories taken up for that Iteration / No. of initial user stories planned for the iteration

▪ Estimated velocity of user stories taken up for that iteration / Estimated Velocity of initial planned user stories

▪ No.of user stories Accepted by Product Owner / No.of User stories taken up for that Iteration.

▪ Actual velocity of accepted user stories/Total effort spent by team for that Iteration.

▪ Actual efforts-Planned efforts)/(Planned efforts)

Misconceptions about Agile

▪ Agile is all about coding and no documentation

▪ Agile will solve all engineering problems

▪ Agile delivers better quality

▪ Agile is for small projects

▪ Agile gives freedom to change anything anytime

▪ Lets experiment agile on a non-critical project

▪ Let’s start agile slowly

▪ We have daily stand-up meetings, so we are agile

Myths about Agile

▪ Agile Means “We Don’t Plan”▪ It may seem that no planning occurs, since reliance in on collaboration▪ In reality, planning is incremental and evolutionary, instead of

planning all activities in one go

▪ Agile Means “No Documentation”▪ Agile Team’s documentation is light weight as much as possible▪ They DO document their solutions as they go▪ They document continuously, writing executable specifications

Conclusion

▪ Scrum is hard, But it is sure a whole lot better than what we were doing before!

Bibliography▪ www.goodagile.com

▪ www.scrumalliance.com

▪ Article titled 'The Scrum Primer v2.0' by Pete Deemer

▪ Article titled 'The Scrum Guide' by Ken Schwaber and Jeff Sutherland

▪ Articled titled 'Scrum – a description' from Scrum Alliance, Inc

▪ Articled titled 'Agile in the IT world' published by KPMG, India

▪ Book titled 'Agile Project Management for Dummies' by Mark C. Layton, 2012

▪ Book titled 'Agile for Dummies – 2nd IBM limited edition' by Amy and Berniew.

▪ Book titled 'Fun Retrospectives' by Paulo Caroli and Taina Caetano

Courtesy to the Authors

Thank you!

Reference Slides

▪ Poker Planning

▪ User stories and the INVEST approach

▪ Estimating and Ordering the Product's Features

▪ Some industry reports

Poker Planning

1. Provide each member of the development team with a deck of estimation poker cards

2. Starting with a simple user story, the players decide on an estimate — as a story point — that they can all agree on for that user story.

▪ This user story becomes the baseline story.

3. The product owner reads a high-priority user story to the players.

4. Each player selects a card representing his or her estimate of the effort involved in the user story and lays the card face-down on the table.

▪ The players should compare the user story to other user stories they have estimated. (The first time through, the players compare the user story only to the baseline story.) Make sure no other players can see your card.

5. Once each development team member selects a card, all players turn over their cards simultaneously.

To play estimation poker, follow these steps

Poker Planning

6. If the players have different story points: ▪ It's time for discussion. The players with the highest and lowest scores talk

about their assumptions and why they think the estimate for the user story should be higher or lower, respectively. The players compare the effort for the user story against the baseline story. The product owner provides more information about the story, as necessary.

▪ Once everyone agrees on assumptions and has any necessary clarifications, the players reevaluate their estimates and place their new selected cards on the table.

▪ If the story points are different, the players repeat the process, usually up to three times.

▪ If the players can't agree on the estimated effort, the scrum master helps the development team determine a score that all the players can support or determine that the user story requires more detail or needs to be further broken down.

7. The players repeat Steps 3 through 6 for each user story.

To play estimation poker, follow these steps

User stories and the INVEST approach▪ Independent: To the extent possible, a story should need no other stories to implement

the feature that the story describes.

▪ Negotiable: Not overly detailed. There is room for discussion and expansion of details.

▪ Valuable: The story demonstrates product value to the customer. The story describes features, not a single-thread start-to-finish user task. The story is in the user's language and is easy to explain. The people using the product or system can understand the story.

▪ Estimable: The story is descriptive, accurate, and concise, so the developers can generally estimate the work necessary to create the functionality in the user story.

▪ Small: It is easier to plan and accurately estimate small user stories. A good rule of thumb is that a user story should not take one person on the development team longer than half of a sprint to complete.

▪ Testable: You can easily validate the user story, and the results are definitive.

Estimating and Ordering the Product's Features

▪ Effort is the ease or difficulty of creating a particular requirement.

▪ An estimate, as a noun, can be the number or description you use to express the estimated effort of a requirement.

▪ Estimating a requirement, as a verb, means to come up with an approximate idea of how easy or hard that requirement will be to create.

▪ Ordering, or prioritizing, a requirement means to determine that requirement's value in relation to other requirements.

▪ Value means just how beneficial a particular product requirement might be to the organization creating that product.

Some industry reports

▪ On Agile adoption

The Agile Process

Back Logs

Product Back Log Sprint Back Log

Prioritized list of customer centric features as user stories maintained by the product owner

Subset of product back log and list of work to be done in the sprint

Never complete. Evolving list of requirements with larger and exhaustive details.

User stories picked up by the team during sprint planning meeting

Single, definitive view of ‘everything that could be done by the team ever, in order of priority’

Team develops the new product increment defined by the sprint backlog.

Includes new customer features, bugs, fixes, functions, engineering improvement goals, research work, and possibly known defects

Highly visible, real-time picture of the work the team plans to accomplish.

Many teams use ‘Scrum Boards’ with ‘Post-it’

notes labeling To-Do, In-Progress and Done.