The document outlines 21 challenges faced by Scrum Masters, including failing to meet commitments, poor estimations, lack of focus on sprint work, disorganized sprint reviews, low collaboration, insufficient ticket information, frequent scope changes, delivering nothing at the end of sprints, low motivation, reprioritizing features mid-sprint, lack of communication of company strategy and roadmap, inadequate backlog grooming, unclear quality ownership, poor timekeeping, lack of development improvements, teams that do not care about quality, lack of code transparency, insufficient test automation, deficient triage processes, limited DevOps practices, and code not being checked in daily.

1. Scrum Master Role
Focus on challenges.
Top 20 Scrum Masters’ challenges in 2016

2. About
 This slide deck covers the top 20 challenges faced by Scrum
Masters from my own personal experience.
vireshdoshi@time2test.co.uk
2

3. ME
 I’m a scrum master with a background in Quality Assurance
and Test Automation with over 15 years industry experience.
 My work life started working on Air Traffic Control Systems.
 I love my coffee.
 I am a keen advocate of process improvements and test
automation.
vireshdoshi@time2test.co.uk
3

4. #1 meet a commitment
 Are you failing to meet your commitments?
 At the sprint review meeting , allow the team to demonstrate
their work.
 If a commitment does not pass the automated tests or
acceptance criteria then “respectfully” fail it
 Discuss in the retrospective.
 Remember that the team is accountable and not the individual.
vireshdoshi@time2test.co.uk
4

5. #2 estimations
 Are your estimations poor?
 Discuss how the team came up with the estimation
 Discuss complexity and effort
 What have you learned and what new things should be
factored into estimations?
 Consider not using “hours” as an estimation point.
vireshdoshi@time2test.co.uk
5

6. #3 focus
 Are you working on tickets outside the spriint?
 During daily stand-ups, identify non related sprint
conversations, requests, work done.
 Is the customer emailing the developer directly?
 Is the operations team taking time away from the scrum team?
 Record this time and factor this in.
vireshdoshi@time2test.co.uk
6

7. #4 polished sprint reviews
 Is your sprint review hap hazard?
 The sprint review is where you showcase the sprint commitments to the
scrum team, product owner, customer and wider audience.
 Does the showcase flow?
 Practice the demo
 Can everybody see the screen?
 Timebox and cross reference the acceptance criteria
 Run the automation tests perhaps in BDD
vireshdoshi@time2test.co.uk
7

8. #5 collaboration
 Ensure that the QA/Dev and Product Owner are talking
 Look out for engagement levels in the team
 Look out for information on wiki and/or tickets
vireshdoshi@time2test.co.uk
8

9. #6 info in the tickets
 Are you experiencing “not enough information in tickets?”
 Can the ticket be worked on?
 Is this a live issue?
 Can you reproduce in development?
vireshdoshi@time2test.co.uk
9

10. #7 sprint scope change
 Are you experiencing sprint commitment scope changes?
 Scope change can de-motivate the team
 Manage and explain this to the team
 Introduce systems to allow for teams to multitask
 Try to deflect to future sprints
vireshdoshi@time2test.co.uk
10

11. #8 nothing delivered
 Nothing delivered at the end of the sprint
 Something fundamental has gone wrong
 Perhaps, split up stories further
 Understand what went wrong
vireshdoshi@time2test.co.uk
11

12. #9 motivation levels
 Look out for signs – keep your finger on the pulse
 Involve the team
 Celebrate success/ understand failures
 Allow the team to be open
 Be transparent
 Share and collaborate
vireshdoshi@time2test.co.uk
12

13. #10 re-prioritize features mid-spirit
 Understand the progress during daily stand-ups
 Re-prioritize a feature and perhaps de-scope to meet a
commitment.
 Get buy in from Product owner
 Increase the Agility of the team
vireshdoshi@time2test.co.uk
13

14. #11 strategy
 Share the roadmap and strategy
 Share the company dream
 Recommend to do this every 3 months
vireshdoshi@time2test.co.uk
14

15. #12 backlog grooming
 Introduce a process to allow the backlog to mature.
 Provide improved estimates.
 Discuss best practices.
 Help the commitment
vireshdoshi@time2test.co.uk
15

16. #13 quality ownership
 Quality is owned by the team
 Documentation, deliverables, scripts, artifacts
vireshdoshi@time2test.co.uk
16

17. #14 time keeping
 Time boxing
 Keep to the times
 Watch the clock!
 Keep focus and stay on the topic
vireshdoshi@time2test.co.uk
17

18. #15 introduce dev improvements
 Introduce development only improvements tickets to the sprint
 Automation frameworks integration into CI
 Tools development
 New environment provisioning
 DevOps
vireshdoshi@time2test.co.uk
18

19. #16 get the team to care
 Success will come from a team that cares
 Let the team decide
 Self organizing
 Discuss importance to the business
 Get buy-in
 Dictator or facilitator?
vireshdoshi@time2test.co.uk
19

20. #17 code transparency
 Introduce systems to allow for code transparency
 Introduce processes to allow for quality code reviews
vireshdoshi@time2test.co.uk
20

21. #18 test automation
 Introduce systems to allow for test automation
 Think BDD
 Think Gherkin
vireshdoshi@time2test.co.uk
21

22. #19 triage process
 Enrich tickets with tags and data to allow for better searching.
 Production data attached
 Do you have enough information?
vireshdoshi@time2test.co.uk
22

23. #20 devops
 Think continuous integration
 Think continuous delivery
 Think one click automation
 Use virtual machines
 Think build pipelines
vireshdoshi@time2test.co.uk
23

24. #21 code check-in charter
 Ensure that code is checked in daily
vireshdoshi@time2test.co.uk
24