Agile Scrum

STRICTLY PRIVATE AND CONFIDENTIAL – DO NOT FURTHER DISTRIBUTE
Scrum

2
Why Scrum?
What is Scrum?
Scrum Artifacts?
Is it ready? Is it done?
Estimation!!!
The Scrum Team
The Scrum Events
Reports
Notes
Table of contents

3
Why?
Why Scrum?
 Fast reaction to changing requirement “changes are welcome”
 1-4 weeks for sprint provide sense of urgency & reduce risk
 Shippable increment early and often
 Continues feedback cycle
 Productive meetings
 Transparency
 Clear goal, high focus
1

4
What?
What is Scrum?
 Framework for developing complex products
 Iterative process; Planning, Analysis, Develop, Test,
Iterate, Deploy
 Learning loop; Learn -> Build -> Measure
1

5
Scrum Artifacts
Product Backlog
The Product Backlog
 The single point of truth
 An ordered, single source list of everything that is known to be needed in the
product
 Product Backlog item attributes (Description, Order, Estimate, Value)
 Owned by the Product Owner, however, anyone may add items for the product
owner consideration
 If Product Backlog is not ready the sprint planning is canceled

6
Product Backlog
Definition of Ready & Done
Is it ready?
 A checklist defining a product backlog item as ready to
be included sprint planning
Is it done?
 A checklist defining a quality standard of finished story
 Tested? Deployed to a testing environment?
Ongoing process, revisited and refined

7
Scrum Artifacts
Sprint Backlog
The Sprint Backlog
 A forecast containing a set of Product Backlog items selected for
this sprint
 A plan for delivering the product Increment and realizing the
Sprint Goal
 Defined by development team and product owner
 Visible to all to meet the sprint Goal

8
Estimation
In Scrum, an estimate is one of four attributes of a Product Backlog item,
just like value, description and order
Why Estimate? It’s hard
 Estimation serve to achieve Transparency, Inspection, Reduce uncertainty
 It’s Time consuming! It could be that we are doing it on too much of a micro level
 I need more information! The more teams fear wrong estimations, the more time
consuming and frustrating it is to achieve estimates. To this I can only say that
estimates are always uncertain
 By using estimated (complexity and/or value) we can measure how much can be
completed each Sprint
 Just get it done in time mindset generally results in just bad product done too late
https://medium.com/serious-scrum/estimation-103de626551e, https://www.scrum.org/resources/blog/what-scrum-says-about-estimates,

9
Estimation
Story point VS. Hours?
 Traditional teams give estimates in a time format: days, weeks, months
 Agile teams use story points. rate the effort in a Fibonacci-like format: 0, 0.5, 1, 2,
3, 5, 8, 13, 20, 40, 100
Why used use story points?
 Dates don’t account for the non-project related work emails, meetings … etc
 Story points reward team members for solving problems based on difficulty, not
time spent. This keeps team members focused on shipping value, not spending
time
 Team velocity will be measured which makes it impossible to play politics using
velocity as a weapon
https://www.atlassian.com/agile/project-management/estimation, https://medium.com/@mdalmijn/12-common-mistakes-made-when-using-
story-points-f0bb9212d2f7,

10
Estimation
Story point, but How?
How do we estimate using story points?
 Using an exercise called planning poker
 The team will take an item from the backlog, discuss it briefly, each
member will mentally formulate an estimate.
 Then everyone holds up a card with the number that reflects their
estimate
 If there is a big difference take some time to understand why
https://www.atlassian.com/agile/project-management/estimation,

11
Estimation
From Story point to days, possible but not recommended
Here is a sample calculation
 Assuming we have 10 days sprint duration an team velocity is 20 points per sprint
 Average Velocity = Sprint Duration / Velocity
 Days = Story Point / Average Velocity
https://www.mountaingoatsoftware.com/blog/dont-equate-story-points-to-hours,

12
The Scrum Team
We are one team
Who are we?
 Product Owner
 Scrum Master
 Development Team

13
The Scrum Team
The Scrum Master
The Scrum Master
 Ensure Scrum is understood
 Does not decide what work to be done
 Work toward higher level of quality
 Cannot be the Product Owner
 Help the team organize it’s own work
False Responsibilities
 it is NOT the responsibility of a Scrum
Master to get status updates from the
team during a Daily Scrum, this
should be done by the development
team before the daily scrum
https://medium.com/serious-scrum/the-scrum-masters-responsibilities-7ee05cae707e,

14
The Scrum Team
The Product Owner
The Product Owner
 Single point of accountability
 Owns and manages the Product Backlog
 Any item included in the Product Backlog should be ordered, signed off by the
Product Owner
 Ensure the highest values items are ordered and Ready
Consideration
 Is a single person cannot be a
committee Why?

15
The Scrum Team
The Development Team
The Development Team
 Development Team (6+-3)
 Select the work and chooses how to do it
 Accountability is shared
 Work remaining is updated daily before the daily scrum
Consideration
 Members of the team shall not be
changed during the sprint

16
The Scrum Events
Time boxed events/meetings

17
The Scrum Events
The Sprint
The Event Rules
 Short duration limit risk
 30 days or less - could be adjusted
 Create focus - limit ad-hoc
 Must have one Goal

18
The Scrum Events
Sprint Planning
The Event Rules
 At begging of each sprint (2 hour per week)
 Requires a Product Backlog to produce a Sprint Backlog
and Goal
 One Goal and How to achieve it
 Estimate Sprint Backlog items
 “Multitasking Makes You Stupid. Doing more than one
thing at a time makes you slower and worse at both
tasks. Don’t do it. If you think this doesn’t apply to you,
you’re wrong—it does.”
― Jeff Sutherland

19
The Scrum Events
Daily Scrum
The Event Rules
 Same time each day(15 minute )
 For and by the development team
 Inspect & adapt sprint backlog
 Monitor progress

20
The Scrum Events
Sprint review
The Event Rules
 At the end of development time (1 hour)
 Scrum team + everyone who cares to see
 Team shows the completed work
 Ask “What do you think?” (collect feedback)

21
The Scrum Events
Sprint retrospective
The Event Rules
 At last day of the sprint
 Only the Scrum Team, create a plan for improving
 Refine or expand the definition of Done

22
The Scrum Events
Product Backlog Grooming
The Event Rules
 Product Backlog Grooming
 Product Owner & Development team collaborate to;
Add details, estimates, order items
 Not time boxed event, it’s an ongoing process
 Development teams makes effort and estimates
 Product owner provide details and priorities
 Groom at least 2 sprint in advance

23
The Scrum Events
Too many?

24
Reports
Burndown Chart
 Actual vs Estimated amount of work
Sprint Report
 List of completed/uncompleted stories at the end of
sprint
Version Report
 Team progress toward a completion of a version
 Predict the release date
Velocity Chart
 Amount of value delivered in each sprint in Story
points
 Measure the team velocity

25
Final notes
What else?
 The tool, Trello is not good enough, JIRA?
 Cost? https://www.atlassian.com/software/jira/pricing

www.prestacap.com
Questions?

Agile Scrum

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Similar to Agile Scrum

Similar to Agile Scrum (20)

Recently uploaded

Recently uploaded (20)

Agile Scrum