I think some Scrum Masters *are* pretty useless, to be honest.

Their teams are stuck doing “Zombie Scrum”, and they go through the motions checking off the easy boxes in the Scrum Guide and ignoring all of the difficult stuff. They lack any core competencies in

– leadership, conflict resolution, negotiation and communication
– business, products and product development
– the agile and lean software development lifecycle
– teaching, coaching and mentoring

and just clutch a certificate that took a couple of days (and maybe a test) to collect, thinking that’s all they need.

The team is your product; if you have no vision for how that team needs to evolve, what a high performance team looks like, and how to shift the organisation in that direction then perhaps they are right?

I hate to break it to you, but Story Points were only ever thinly obfuscated time.

See : https://twitter.com/ronjeffries/status/307469737305186304

They were invented as a way of keeping management out of the team’s estimates, in situations when it was very much “the team Vs the manager.” As with most conflict avoidance approaches, it failed horribly. Managers started to latch onto story points as a productivity measure, and we get all kinds of dysfunction.

The second bit of bad news I have is that agile does not mean “no planning”; nor does Scrum for that matter. Take a look at the 2017 Scrum Guide, and in particular the Sprint Review. The Product Owner needs to have a decent grip on forecasting both time and budget at that operational planning horizon, so that choices can be made.

In Scrum, your product owner should have at the very least a Product Goal, and a roadmap of the key Sprint Goals to reach it. As with any other plan, it’s not fixed. You’ll inspect and adapt that plan at every Sprint Review, with the customers and stakeholders.

If you are using other approaches like the Kanban Method, then you have your “upstream Kanban” of features – each ideally expressed on a lean business canvas as a testable hypothesis, and a statistical delivery forecast based on the pervious cycle time for stories and features.

At that point, you can have a conversation with the Project Manager about how agile forecasting and planning works.

– with Scrum, each Sprint can be considered a mini-project (see the Scrum Guide); the most important question each Sprint Review is “do we need another Sprint, or is there more value to be obtained elsewhere?”

– with Kanban Method, we are continually reforecasting delivery dates in a probabilistic, based on historical data

– in all cases, we are assuming we might have build the wrong thing, or built the thing wrong. In order to reduce the risk of delay and expensive rework, we are delivering iteratively, and incrementally

So – you might have to have some courageous conversations on this one, but I’d advocate having a clear planning and forecasting alternative to a Gantt chart before you do.

You guess. And you’ll be wrong. And that’s okay.

Capacity is just a mechanism to help the team determine a Sprint Goal they can deliver; they’ll then inspect and adapt daily to meet that goal. But it’s okay to make a prediction (ie a Goal), get it wrong, then inspect and adapt.

I’d suggest it’s more important to slice the work down into stuff that 1-2 people can do in 1-2 days, and make sure the team understands the work. A bunch of other stuff won’t go well in the first Sprint too.

So – you’ll have a lot to unpack in the retrospective…