This document discusses how to make sprint retrospectives more data-driven and effective. It recommends collecting both objective metrics like burn down charts and velocity, as well as subjective feedback from the team. The data should be presented using tools like Jira to surface insights and guide the retrospective discussion. Setting clear expectations for the retrospective, tracking action items, and adapting based on learnings are emphasized as keys to success. Data-driven retrospectives can help teams continuously inspect and adapt their processes.

1. DATADRIVEN
APPROACH
TO
RETROSPECTIVES
APOWERFULWAYTOINSPECT & ADAPT
BY SANDHYA BHAYANA

2. “The definition of insanity is doing same thing over and
over again, but expecting different results”
"Themeasureofintelligenceisthe
abilitytochange."
2
- Albert Einstein

3. Think like a
Chef
Not Cook..
Be Adaptive!

4. NEEDOF
RETROSPECTIVES?
 It’s a safe space for people to share honest feedback.
 Allows the team, as a group, to evaluate its past working cycle.
 Gives an Important moment to gather feedback on what went
well and what did not.
 It gives an Opportunity to inspect & Adapt, Identify potential
pitfalls & mistakes and create a plan to define actions that
may improve things
Ultimately, purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness in the process.

5. RELATIONSHIPBETWEENAGILEANDRETROSPECTIVES

6. 6
We follow
many
Retrospective
Techniques

8. 8

9. Andmanymore.

10. AREYOURRETROSPECTIVESSTILLMISSINGSOMETHING?

11. HereistheAnswer
Data Driven Retrospectives

13. SIGNIFICANCEOF
DATAINPROJECT
EXECUTION
• Keeping you realistic about your plans
• Gives ability to make Informed & Rational Decisions
• Improves Project stakeholder Management
• Sets the expectations right
• Identification of areas of improvement
• Helps in managing Project Risks early in cycle
• Helps in Predicting Time Delays
• Gives an opportunity to Pause & revisit if a process is working for the team
• Building a transparent and adaptive team culture.
• Promoting a culture of ownership, accountability and self-directed learning
for your team’s growth in all aspects of their agile practice and process.
• At Last, Data Driven approach is always better than what your Gut says

14. Whattypeofdatashouldwebringin?
14
Objective
Data
“Hard”
Subjective
Data
“Soft”
Data Types

15. Whatdatashouldwebringin?
15
Objective
Data
“Hard”
• Burn Down Charts
• Estimated Vs Remaining
• Velocity
• Time in Status
• Percent of time spent on bugs, features, ad-hoc
requests, drags & Overhead
• No of Prod issues received
• Business Data like NPS, CSAT
Data Types
Includes Info which can
be measured & verified

16. Whatdatashouldwebringin?
16
Subjective
Data
“Soft”
• Includes personal opinions,
feelings, and emotions
• Highs & Lows
• Mad Sad Glad
• Liked, Learned, Lacked, Longed
• Team Radar
• Anonymous surveys
Data Types

17. UsingJiratoPresentFacts
DSM Sprint Retro Quarterly Retro
• Epic Burndown chart & Sprint wise Burn Down charts
• Team Velocity trend
• Discovered Scope
• Committed Vs Delivered Tickets
• Capacity Vs Logged Vs Drags Time
• Estimate Deviation in Epic, Sprint & Quarter
• Drag & Overhead Time Categorization
• Timelines Anticipated vs Actual
• Business Value Delivered
• Dashboards – Shipped SLA, Prod Issues Influx vs Resolved, Prod issues
Backlog, Withdrawn Tickets, Adopted Tickets Post PI, Quarterly Hours
Logged by Category
• Burn Down Chart
• Jira Sprint Health Gadget
• Remaining estimate
• Estimated Vs Logged Time
• Drag & Overhead Time
• RAID Boards
• Dashboards – High Sev & OOSLA
issues, Tickets certified but not
released, Missing epic links, High
Sev Prod issues missing RCA fields
• Burn Down Chart
• Committed Vs Delivered
• Capacity Vs Planned Vs Logged Time
• Capacity Vs Logged Vs Drags Time
• Drag & Overhead Breakdown & Time
• Velocity
• Discovered Scope
• Dashboards – Shipped SLA, High Sev & OOSLA
issues, Tickets certified but not released, Prod
Issues Influx vs Resolved, Prod issues Backlog,
Missing epic links, Ungroomed tickets, High
Sev Prod issues missing RCA fields, Tech Debt
Backlog

18. Burn Down Chart
Remaining Estimate Chart

21. Category wise Drags

22. Discovered Scope

23. OtherObjectivewaysofpresentingFacts
Sprint Retro Quarterly Retro
• Planned vs Actual leaves in Sprint
• Features Planned Vs Features Delivered in Sprint
• Features & Prod Allocation Vs Planned Vs Actual
• Service Ownership Allocation Vs Planned Vs delivered
• Time spent in Trainings/other tasks
• Framework Dependencies
• Dependencies on other Teams
• Impact on PI Plan & Quarter health
• Consolidated View of Quarter Stats
• Planned Vs Actual Leaves in Quarter
• Planned Vs Actual Feature work in Quarter
• Features & Prod Allocation Vs Planned Vs Actual in Quarter
• Service Ownership % Allocation Vs delivered
• Time spent in Trainings/other tasks

24. UsingSubjectiveLearningstoPresentFacts
DSM Sprint Retro Quarterly Retro
• Tracking & Closing Last
Retro’s Items
• Reiterating Last Retro’s
Learnings & Appreciating on
Good work
• Tracking Commitments &
Business Value
• Consolidating Mad, Glad, Sad moments
• Reiterating Lessons Learnt & Appreciations
• Identifying Quarter’s Top 5 Pain Points &
Discussing Solution, hence coming up with
Action Items
• Discussing lessons Learned
• Appreciating on achievements
• Tracking Commitments
• Tracking Assigned & Achieved Business Value
• Reiterating Retro’s Learnings in
DSMs

27. STEPSTOMAKE DATADRIVENRETROSPECTIVESEFFECTIVE
27
Get clear on what data
to collect (Qualitative
& Quantitative)
Gather the data
Generate Insights
Guiding Principles
Define Retro Agenda
Decide what to do
Set the right
behaviors & tone

28. PRINCIPLESFORBUILDINGSUCCESSFULRETROHABITS
• Don’t ditch the retro – ever! Host it even if it’s a retro-lite and runs for 15 minutes.
• Be prepared with a consistent agenda, a clear set of ground rules and actions from last meeting to be get an update on
• Collect data from your team’s delivery and collaboration tools before you start
• Drill down into the data, spot the patterns and outliers
• Affirm what you expect to see and shout out the wins
• Address what you didn’t expect to see and set a path (including actions, experiments and ownership) to remediate
• Compare your practices against your own track record and not against other team’s practices
• Set the action you want to take; name a guardrail (target metric) that will focus your attention and keep you on track
• Encourage dialogue, don’t shut it down unless it’s unproductive
• Let the team chose what matters most to them; feel the energy in the room to determine where team members want to improve.
• Monitor experiments for the next several iterations until you collectively feel (and your metrics show) you’ve reached the desired outcome
• Monitor experiments for any undesired impacts on other agile metrics & Get early runs on the board and demonstrate the impact of
experiments (with data of course)

29. TrackingActionItemstoClosure
&
AdaptingbymakingLearningsisthekey!
29

30. TrackingActionItemstoClosure
&
AdaptingbymakingLearningsisthekey!
30

31. QUESTIONS