Effectiveness of any activity heavily depends on how effectively it was conducted. Under agile methodology we have 5 types of meetings and it’s quite vital that they are executed successfully to achieve the expected outcome out of them. Presentation will focus primarily on possible & feasible solutions to address stated challenges along-with related pros & cons. These solutions will not help scrum members but scrum master and product owners too.

1. Manoj Jain
Director – Technology Development
MakeMyTrip.com
Jun 27, 2013 | Bangaluru
Making Effective Agile Meetings

2. meetings!!!
2
Making Effective Agile Meetings
In a meeting, two or more people come together to discuss one or more
topics, often in a formal setting.
http://en.wikipedia.org/wiki/Meeting
Does this sound familiar?

3. agile manifesto
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
• Individuals and interactions over processes
and tools
• Working software over comprehensive
documentation
• Customer collaboration over contract
negotiation
• Responding to change over following a plan
That is, while there is value in the items on the
right, we value the items on the left more
3
Making Effective Agile Meetings

4. 5 agile meetings
• Agile Release Planning
• Sprint Planning
• Daily Stand-up Meeting
• End-of-Sprint Review
• Retrospective
4
Making Effective Agile Meetings

5. agile release planning
Making Effective Agile Meetings
5

6. agile release planning - objectives
• Product backlog
• Planning sprint duration, number and schedule to meet objective of
release
• Agreement on DONE criteria
• Planning customers’ product validation/review
• Planning team structure
• Need and plan for scrum of scrum
• Macro level design envisioning
• Planning QA and SCM
• Planning I18n/L10n (if applicable)
• Security/Performance considerations
• Tools (development/QA/agile etc.)
6
Making Effective Agile Meetings

7. agile release planning – best practices
• Identify theme for release with stakeholder(s)
• Share theme with all scrum team members
• Have realistic duration of a sprint (usually 3-4 weeks)
• Earmark personnel and resources required
• Critically examine need and availability of specific skills e.g. UX
(User Experience), Performance, Security, Accessibility, DBA
(Database Administrator), AppAdmins, I18n (Internationalization),
L10n (Localization) etc.
• Consider geographical dependency of teams
• Consider communication and collaboration means
• Availability of product backlog during release planning
• Ensuring that all members are familiar with high level design
• Planning for CI (Continuous Delivery) process in team
• QA automation coverage to support agility
7
Making Effective Agile Meetings

8. agile release planning – best practices (contd.)
• Agreement on DONE criteria by “ALL” e.g.:
– Coded as per guidelines
– Technical documentation updated
– Unit tested (and passed), 90% coverage
– Integration built
– Functionally & regression tested (functional TCs written and passing)
– All P0, P1 & P2 defects are fixed and verified
– TCs automated (mandatory/optional)
– Meets the acceptance criteria as defined by product owner
• Availability of application to customer(s) for validation
• Discuss frequency and location of scrum of scrum
• Availability of right set of tools & trainings to team
• Sharing minutes of meeting with assignees and due dates
8
Making Effective Agile Meetings

9. sprint planning
Making Effective Agile Meetings
9

10. sprint planning - objectives
• Sprint’s objective is defined by product owner
• Define velocity of sprint (hours burn-down or story points)
• Identify stories to be address in sprint from product backlog
• Seek commitment from team members about their availability and
understanding
10
Making Effective Agile Meetings

11. sprint planning – best practices
• Sprint planning meeting should be for 1 day
• Ensure that all required roles are part of sprint planning viz.:
– Product owner(s), Scrum master, Scrum team, Cross functional
contributors (if applicable)
• Finalize velocity for sprint based on baseline velocity (if available)
and If not then start with best of estimates
• Define user stories in canonical form only e.g.
– As a <user role/persona>, I want to <action/behavior>, so that
<business value>
• Identify stories according to theme of sprint
• Non-functional requirements should be created as tasks
• Use planning poker technique for estimation purpose
• Seek commitments from team members for their stories
• Technical stories should be extracted out functional stories and link
them as child stories
11
Making Effective Agile Meetings

12. sprint planning – best practices (contd.)
• For subsequent sprints
– incorporate learning from previous sprint’s retrospective
– review left overs (if any) from previous sprint and group them as
• Stories which started and couldn’t finish. These must be finished in current
sprint before anything else is picked-up
• Stories that couldn’t start at all. Product owner reviews these stories and
prioritize them if they really need to be picked in current sprint or something
else
• Identify dependencies for stories planned for sprint
• Keep scrubbing stories until they are absolutely clear
• Don’t over or under commit sprint deliverables
• Availability of sprint backlog at end of sprint planning
• Work planned by 2 teams should never be compared
12
Making Effective Agile Meetings

13. daily stand-up meeting
Making Effective Agile Meetings
13

14. daily stand-up meeting - objectives
• Meeting aiming to share progress with scrum team members
• Promote daily commitment
• Vital for cross-function and team communication
• Identify any show-stoppers impacting progress of sprint
• Resolution of impediments with others’ experience
14
Making Effective Agile Meetings

15. daily stand-up meeting – best practices
• Collectively freezing schedule & location of daily stand-up
• Avoiding any changes to schedule and location
• Ensuring that following 3 questions are addressed:
– What I did yesterday?
– What’s plan for today?
– Any impediments?
• All members should literally “stand-up”
• Every one just gets 1 minute
• Avoid getting late or attending calls
• Progress communicated reflects at sprint planning tool
• Review sprint burn down chart (planned vs. actual)
• Show-stoppers raised should be tracked under tool
• All roles involved do participate in daily stand-up meeting i.e.
– Scrum team, Scrum master and Product owner (optional)
15
Making Effective Agile Meetings

16. end of sprint review
Making Effective Agile Meetings
16

17. end of sprint review - objectives
• Informal review of activities planned during the sprint
• Takes place (usually) on the last day of sprint
• Scrum team demonstrates potential shippable product to product
owner and other stake-holders
• Seeks feedback on features demonstrated
• Decides if deliverable is ready for release to customers?
• Has DONE criteria met for potential shippable features?
17
Making Effective Agile Meetings

18. end of sprint review – best practices
• Ensuring following roles participate in sprint review meeting:
– Scrum team, Scrum master, Product owner & Customers
– Others (should limit their inputs to demonstrate feature only)
• All must join from same location and not from their desks
• Remote members may join via web conferencing facilities
• Scrum master must summarize sprint i.e.
– What all stories planned
– Which stories have been completed
– Which stories are in-progress
– Which stories couldn’t be started
– Planned vs. actual velocity
– Impediments faced during sprints
– List of stories to be presented and by whom along-with time-limit
• Only finished stories should be demonstrated
18
Making Effective Agile Meetings

19. end of sprint review – best practices (contd.)
• Demonstrated stories are validated against DONE criteria
• Show ONLY working software and avoid PPTs
• Sprint review meetings should be recorded (for references)
• Seek product owner’s confirmation post feature demonstration
• Discuss why certain features couldn’t be completed
• Plan & share 2 dates before concluding sprint review meeting:
– Sprint retrospective meeting
– Sprint planning meeting for next sprint
• Avoid any blame game and focus objectively only
19
Making Effective Agile Meetings

20. sprint retrospective
Making Effective Agile Meetings
20

21. sprint retrospective - objectives
• Review (reflection) of what took place in sprint:
– What went well?
– What could have been better?
– Areas of improvement for future sprints
• Takes place at end of sprint and before sprint planning meeting for
next sprint
21
Making Effective Agile Meetings

22. sprint retrospective – best practices
• Ensuring following roles participate in this meeting:
– Scrum team & Scrum master
– Product owner (ONLY if team feels that he/she is required)
• It’s an internal meeting of team and must be restricted to team
• Scrum master facilitates meeting (on in rotation by team)
• Focus on issues and any blame game should be avoided
• Encourage “participation” and not just “attendance”
• Each member provides at-least 1 input for each of 3 categories
• Members join in-person and not share their inputs offline
• If a member couldn’t attend meeting (for genuine reasons) then he/she
should share his/her feedback to scrum master before meeting
• Inputs under all 3 categories (listed above) should be duly recorded
along-with action items, owners and due date
22
Making Effective Agile Meetings

23. sprint retrospective – best practices
• Consolidated tracker for all sprint retrospective meetings
• Review open action-items from previous retrospective
• Identify high impact findings/areas (~2-3) and focus on them
• Leverage fish bone diagram for root cause analysis
• Use voting to identify high impact according to team members
• Look for findings that were closed and recurring
23
Making Effective Agile Meetings

24. questions?
24
Making Effective Agile Meetings
manoj.jain@makemytrip.com