2. 4 VALUES OF THE AGILE MANIFESTO
1. Individuals and interactions over processes
and tools
2. Working software over comprehensive
documentation
3. Customer collaboration over contract
negotiation
4. Responding to change over following a plan
3. 12 PRINCIPLES OF THE AGILE
MANIFESTO
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.
4. 12 PRINCIPLES OF THE AGILE
MANIFESTO
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.
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.
5. 12 PRINCIPLES OF THE AGILE
MANIFESTO
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.
7. SCRUM ROLES – PRODUCT OWNER
1. Responsible for Return on Investment(ROI)
2. Responsible for product vision
3. Focused more on the what than on the how
4. Final arbiter of requirements questions
5. Constantly re-prioritizes the Product Backlog
6. Accepts or rejects each product increment
7. Managing the release plan
8. SCRUM ROLES – SCRUM MASTER
1. facilitator, coach, mentor
2. Protects the team from external interference and
distractions
3. Removes impediments
4. Helps the team become self-organizing
5. Enforces Time Boxes
6. Promotes Improved engineering practices
7. Has no management authority
9. SCRUM ROLES – SCRUM DEVELOPMENT
TEAM
1. Cross-functional group
2. Attempts to build a ‘potentially shippable
product increment’ every sprint
3. Collaborates
4. Self-organizing
5. 7+/- 2 members
12. BACKLOG REFINEMENT MEETING
• Participants : Product Owner, Team, Scrum
Master
• Duration: < 10% of Capacity of Team;
2 Weeks Sprint – 1 day
• Decomposition of large Product Backlog
Items(PBIs) into smaller ones (e.g. epics to user
stories)
• Clarification of requirement
• Estimation of effort
13. SPRINT PLANNING MEETING
• Participants : Product Owner, Team, Scrum Master
• Duration: < 10% of Capacity of Team;
2 Weeks Sprint – 4 hours
When : At the beginning of each Sprint
• Agree to Sprint goals and negotiate which items from
Product Backlog will be committed to the Sprint
Backlog
• Team will come up with an initial list of tasks
necessary to complete the committed PBIs
14. SPRINT PLANNING MEETING
• 2 Part Meeting
• Sprint Planning Part 1 (”what”)– for committing to
Product Backlog items (PBIs)
• Sprint Planning Part 2 (“how”)– for coming up
with tasks.
• DONE
Tested
Refactored
Potentially shippable
15. DAILY SCRUM MEETING
• Participants : Development Team, Scrum Master,
Product Owner (optional)
• Duration: 15 minutes each day
• Daily Scrum 3 Questions
1. What did I do yesterday?
2. What will I do today?
3. What impediments I faces?
16. DAILY SCRUM MEETING
Tracking Progress during the Sprint
Every day, the Team members update their estimate of the effort remaining
to complete their current work in the Sprint Backlog.
Initial Estimate
of Effort
0 1 2 3 4 5 6
modify datababase Nilesh 5 4 3 0 0 0
create webpage (UI) Uday 3 3 3 2 0 0
create webpage (javascript logic) Uday & Radhika 2 2 2 2 1 0
write automated acceptance tests Reshma 5 5 5 5 5 0
update buyer help webpage Nilesh & Reshma 3 3 3 3 3 0
merge DCP code and complete layer-
level tests 5 5 5 5 5 5
complete machine order for pRank 3 3 3 3 5 5
change DCP and reader to use pRank
http API 5 5 5 5 5 5
Improve trasaction
processing
performance
Daily Updates of Work Remaining on the Sprint Backlog
Product Backlog Item Sprint Task Volunteer
New Estimates o
Remaining at end
As a buyer, I want to
place a book in a
shopping cart
17. DAILY SCRUM MEETING
Sprint Burn down Chart
It is also common for someone to add up the effort remaining for the
Team as a whole, and plot it on the Sprint Burn down Chart. Graph
shows, each day, a new estimate of how much work remains until the
Team is finished.
If the burn down line is not tracking downwards towards completion
near the end of the Sprint, then the Team needs to adjust, such as to
reduce the scope of the work or to find a way to work more effectively
while still maintaining a sustainable pace.
19. SPRINT REVIEW MEETING
• Participants : Product Owner, Development
Team, Scrum Master, Other Stakeholders
• Duration: 2 hours for 2 weeks Sprint
• When: At the end of Sprint
• Agenda
1. Product Demonstration
2. Product Owner declares what’s done
3. Measure Velocity ( optional )
4. Stakeholder feedback
20. PRODUCT BACKLOG
• Example
• As a <student>, I can <see my previous semester grades
online> so that <I don’t have to wait until I get to school to
know my previous grades>
• Acceptance Criteria: Columns align neatly on FingerFly
4.1 and JPhone
• EFFORT : SMALL
21. SCRUM USER STORIES
Format
As an [actor], I [want|must] [action] so that [achievement]
Or in a shorter version:
As an [actor], I [want|must] [achievement]
Example
• As a <customer> I want to <see the catalogue of saleable
items> so that <I can order one of them>
• As an <administrator> I want <be able to disable
accounts>
22. VELOCITY
Measure Velocity
• PBIs declared as done are one Medium ( 4 Story Points),
one Small( 2 Story Points ) and one Small( 2 Story Points)
• Using relative sizing numbers, velocity works out to 8 story
points the Sprint
• PBIs DONE or Velocity = 4 + 2 + 2 = 8 Story Points
• If velocity stays stable for serval sprints it may eventually
help you forecast how far down the Product Backlog you’ll
get before the release date.
23. SPRINT RETROSPECTIVE MEETING
• Participants : Development Team, Scrum Master,
Product Owner (Optional)
• Duration: 1.5 hours for 2 weeks Sprint
• When: At the end of Sprint ( after Sprint Review)
• Sprint Review meeting involves inspect and
adapt regarding the product.
• Sprint Retrospective involves inspect and adapt
regarding the process and environment.
24. SPRINT RETROSPECTIVE MEETING
Purpose
Inspect how the last Sprint went with regards to
people, process, and tools.
• Identify and order the major items that went well
and potential improvements.
• Create a plan for implementing improvements to
the way the Scrum Team does its work.
25. SPRINT RETROSPECTIVE MEETING
• By the end of the Sprint Retrospective, the Scrum
Team should have identified improvements that it
will implement in the next Sprint. Implementing
these improvements in the next Sprint is the
adaptation to the inspection of the Scrum Team
itself.
27. PRODUCT BACKLOG
List of desired functionality
Visible to all stakeholders
Any stakeholder can add items
Constantly re-prioritized by Product Owner
Items at top are more granular than items at
bottom
Maintained during the Backlog Refinement
Meeting
28. PRODUCT BACKLOG ITEM(PBI)
Specifies the what more than the how of a
customer centric feature
Often written in User Story form
May have item-specific acceptance criteria
Effort is estimated by the tem, in relative units
(e.g. story points)
Effort is roughly 2-3 people 2-3 days
Account lockout after three
attempts
Acceptance Criteria: ....
Small
29. SPRINT BACKLOG
Consists of committed PBIs negotiated between the
team and the product owner during Sprint Planning
Meeting
Scope commitment is fixed during Sprint Execution
Initial task are identified by the team during Sprint
Planning Meeting
Team will discover additional tasks needed to meet the
fixed scope commitment during Sprint execution
Visible to team
Referenced during the Daily Scrum Meeting
31. SPRINT TASK
Specifies how to achieve the PBIs what
Requires one day or less of work
Remaining efforts is re-estimated daily, typically in
hours
determine requirements for password policy
page layout(design)
get latest JBoss running
choose persistence strategy(Hibernate?)
write code(using test driven development)
exploratory testing
32. SPRINT BURN DOWN CHART
Indicates total remaining team task hours within
one Sprint
Re-estimated daily
Hinweis der Redaktion
C
What’s the difference between the Product Backlog and the Sprint Backlog?
- The Product Backlog contains everything we might ever work on, while the Sprint Backlog contains just the things we’ll work on during one Sprint.
Q#1 Test Driven Development TDD involves creating tests and code nearly simultaneously while constantly improving the design. Is TDD part of Scrum?
Ans: No.Scrum is only a feedback framework. It does not specify particular technical practices.
Q#2 What is a good size for a Sprint Task?
Ans: One person-day or less
Q#3 How often do scrum teams integrate their work and rerun the regression tests?
Ans: Continuously as things change; potentially many times per day
Q#4 When is Sprint execution completed?
Ans: When the timebox expires
Tracking Progress during the Sprint
Every day, the Team members update their estimate of the effort remaining to complete their current work in the Sprint Backlog
It is also common for someone to add up the effort remaining for the Team as a whole, and plot it on the Sprint Burndown Chart. graph shows, each day, a new estimate of how much work remains until the Team is finished.
If the burndown line is not tracking downwards towards completion near the end of the Sprint, then the Team needs to adjust, such as to reduce the scope of the work or to find a way to work more effectively while still maintaining a sustainable pace.
regression testing using continuous integration server
+ exploratory testing
Q#1 What's a good use for velocity?
Answer: To help the Product Owner make forecasts about what might be done by a given release date.
----------------------
Small - 1 man days
Medium - 2 man days
large - > 2 man days
Team 4 members - 2 weeks sprint - Capacity 40 man days
Velocity 24 Story Points
Book
Agile Retrospectives by Esther Derby/Diana Larsen
Actions
1) Move daily Scrum time from 9AM to 10AM
2) Clarify definition of done
3) Take on less work next Sprint Planning Meeting
4) Slice PBIs smaller during Backlog Refinement
5) Amend team agreements regarding coding conventions
Impediment Backlog
current list of things that are preventing the team fro progressing or improving
Impediment Backlog
current list of things that are preventing the team fro progressing or improving
3) Sprint Burndown Chart
-> Indicates total remaining team task hours withing one Sprint
-> Re-estimated daily
Figure Sprint Burn down Chart