Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.



No description

on 19 March 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Agile

What is agile and what are its benefits?
Key principles of Agile
Agile best practices
12 Agile Principles
Traditional Software development model vs Agile
Traditional waterfall model calls for a fully formed idea up front
Agile approach can build on a vague idea, validate it and then slowly build up quality on it. Stop when diminishing returns are encountered.
Agile focus: are we building the right thing?
Scrum at a Glance
Name given to a group of software development methods
Based on iterative and incremental development
Focus is on the delivery of a real product early and often
Must respond to change
Must preserve agile values and principles
What is Agile Development?
Mind map of agile values
Scrum Values
Product owner
Scrum Master
Team: Dev & Testers

Time Boxes
Release planning meetings
Sprint planning meetings
daily scrum
sprint review
sprint retrospective
Product Backlog
Sprint backlog
Sprint burndown
Release burndown

Scrum Framework
Product Owner
Maintains and owns product backlog
Prioritizes the product backlog - Ranking backlog items
Roles and Responsibility
Scrum Master
Implements scrum within the teams
Removes impediments to the team
Coach for the team, helping the team do the best work it possibly can
Facilitating meetings
Working with the product owner to make sure the product backlog is in good shape and ready for the next sprint.
Make sure team does not over commit
Role is commonly filled by a former project manager or a technical team leader but can be anyone.
Team Members
Developers and Testers
No specific titles
Chosen for their core skills
Responsible for delivering quality software quickly
Responsible for communicating progress and impediments

Scrum Practices
Release Planning (0.5-1 days)
Attendees: customer, PO, Scrum master and development team (dev & test)
based on road map
PO defines a list of user stories
Dev and test team allocate estimates to the user stories
Propose we have a dev time in main item and a subtask for qa time
Using the developers' estimates and the customer's feature priorities, the team lays out a release plan,
Its rough schedule on what features will be delivered and in what time frame
Release typically range between 2 and 12 months
May find you don't always have to have a release planning meeting and its sufficient to just have sprint planning.

Sprint Planning (1-2hr)
attendees: PO, scrum master and development team (Test and Dev)
Team helps users to prioritize the user stories
prior to meeting PO should prepare product backlog and detail requirements
team must commit to user stories for sprint
Daily standup's (15 min)
attendees: Scrum master, PO, Team
same location same time (usually morning)
What we talk about
1. What we did yesterday
2. What we are doing today
3. Any problems we are facing
conflicting priority eg. critical blocker issues from support,

Sprint review meeting (1-2hr)
attendees: team, PO, scrum master, selected stake holders
Dev team present/demonstrate user stories that are completed
After presentation stake holders provides changes and inputs to the team which is moved to the product backlog
Stake holders free to voice comments
Sprint Retrospective/Release retrospective (1-2hrs)
Attendee: PO (optional). scrum master, dev team
Most important meeting
Scrum master facilitates meeting (typically)
Facilitator encourage team to discuss
what went wrong
what went right
action items for improvement
Action items are input to next sprint
Scrum Team Analogy

The scrum team is the car itself, ready to speed along in whatever the direction it is pointed

the product owner is the driver, making sure that the car is driving in the right direction

the scrum master is the chief mechanic, keeping the car well tuned and performing at its best

Information Radiators
Information at a glance
burndown charts
velocity graphs
build status
Note: Update tasks completed at the end of each day to keep burndown chart most up to date
Team Space
Ideal team space:
minimum distractions eg. phone calls, IM, foot traffic
good hygiene factor eg. decent air, good lighting, comfy seats
Information Radiators
necessary space
everyone vital to project in same work space
Bad team space:
minimal interaction
ugly workspace
seating arrangement by job description
lack of Information radiators
too many partitions
team members not engaged

Agile planning and Estimation
Innovation games
Innovations and Estimation
Accuracy of estimates vary over time of project
Techniques : Planning poker, Affinity estimation
Planning poker
Technique that is consensus based
1. PO or customer reads agile user story
2. estimators discuss feature, asking questions if needed to get a better understanding
3. each estimator (tester and dev) select a card to represent his or her estimate
4. all cards revealed at the same time
5. all estimates the same, that then becomes value, else estimators justify their estimates. Esp the high and low estimators.
6. estimators estimate again in secret and revealed again at the same time.
Steps 3,4,5 and 6 repeated till a consensus is achieved or until decided that more information is required for estimation.

Sequence of cards recommended. The values represent ideal days, story points or
whatever units the team chooses to estimate with
Affinity Estimation
quickly and easily estimate a large number of user stories in story points
good technique when starting a project

Story points vs ideal days
Story point:
estimating in story points is typically faster - relative estimates
story point determination is a collaborative effort
story points is a measure of size of the story item. This does not change over time and is independent of experience of team members
it is a relative size estimate that can't be complicated by outside pressure
new to story point, not so comfortable to estimate with
hard to explain to upper management

Ideal days:
ideal days are easier to estimate at first
ideal days make velocity predictions easier
each part of the team estimates how long thier part will take - not very collaborative
ideal days vary depending on experience (both project and people)
ideal days not the same per person
Work break down structure in Agile
User story
Customer or product owner writes the story
Story format: As a <role>, I want <goal> so that <benefit>
Stories should be small and testable
Estimates done against a story
Collection of related stories is an epic
Write acceptance criteria for story
Stories should be as independent as possible
if dependency exist think about combining them in to a larger story
Link dependency of story
Quality in Agile
Agile approach to projects
agile team works as one
agile team works in short iterations
agile team delivers something each iteration
agile team focuses on business priorities
agile team speculate explore and adapt
Frequent Verification and validation
verification : am i building the right product
validation: am i building the product right
customer gets to review, test and accept/reject implemented features each iteration
frequent verification and validation of feature is accomplished within each iteration . ie. code reviews, unit tests and functional testing

Test first Development

1. add a quick test, basic code required so that test fail
2. run the tests, with complete test suite
3. write the functional code to pass the test
4. run the test again
5. if the test fail return to step 3
6. if test pass, move to next feature
documentation of design JIT before writing the code
testing code available to validate work
re factoring
improve design
bug is found, write a test to test the bug, fix it and run test.

Continuous Integration
Automated process of: build -> test -> deploy

Performed continuously
after each commit or specific intervals
integrate code every time
keep build, tests, and other release infrastructure up to date
single integration environmnet
Full transcript