As a Scrum Master, how to handle management expectations on delivering story points?

Question

Problem - I've been appointed as a Scrum Master to a new team and senior management (CTO) expectation is that our team should deliver more than the SP capacity we can currently realistically deliver.

This SP expectation is based on previous (over an year ago) estimates. A lot has changed since then. The application has become more complex since then, there are new developers and some developers left.

Senior management now brought in a new developer in and they hope that will help the velocity but I told them the velocity will go down and only after a while go up. They should also consider the stress on the testers.

How to approach such situation with senior management?

---

More background on me and what I have tried:

• I was a Scrum Master for one year in another project
• I worked with team to break larger stories down because when they carried over a task from one sprint to another it was always big.
• Went with a lower velocity that is based on the latest velocity and sprints.
• Remove impediments and act as the scrum master (The team thought they can do it themselves) in areas such as planning, stand up's etc..
• Promote pair programming (Not mentioned in scrum but helped the team a lot)
• I did proper retrospectives (As mentioned by Esther Derby)

Answer 1

You are doing the right things and acting as a Scrum Master should.

It sounds like you may need to do some coaching, explaining to the team, to management and to the stakeholders how Scrum works.

Try and back up as much as you can with evidence, such as quotes from The Scrum Guide, from articles and blog posts on reputable websites.

It would also be good to get the support of other agile advocates in your organisation. It sounds like there is a considerable amount of education needed.

Educating your Scrum team is particularly important as they should also be pushing-back against anti-Scrum behaviour from the rest of the organisation.

Answer 2

Not sure if it would help, but an analogy I often used is comparing velocity to your time on a 5K run. (credit where it's due, I adopted the analogy from Mike Cohn) It's only observable. If you think, "I'll just run harder" you'll just burn yourself out early in the run and probably get a slower time. Instead, you can take actions that you think will improve your time (different breathing, better diet, different stretches, etc) and then observe how it effects your time after the next run.

Velocity works exactly the same. If I just try to increase my velocity through force of will, I'm going to either decrease it inadvertently or (because it's easier to game than time) I might create the illusion of an increase. Instead I need to take actions like improving collaboration, removing technical debt, automated testing, etc. and then observe how those impact my velocity in following sprints.

Answer 3

I agree with Barbaby Golden, and would like to add what helped when I wanted to show the impact of changing the teams often:

• Show the management the velocity that is achieved in the last X sprints to show what they can do,backed up with actual numbers

• Check when developers left / joined and see if there is a noticeable change in the velocity around that time to show what the impact is

For me this has worked, I use the sprint report in Jira to create an overview of the last 20 sprints (it was a lot of work) but I was able to convince management about the impact of changing the team constantly.