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

More Related Content

What's hot

Similar to Agile Scrum

Recently uploaded

Agile Scrum