There’s a bit more to the Kanban Method than just pulling stories from a to-do column into in progress. Ideally you

– visualise the entire workflow through to the customer using the product
– split each column into “doing” and “done” sub ciolumns
– have swim lanes for different classes of service
– monitor Kanban metrics like lead time, cycle time and throughput

Over time, tools like a “cycle time histogram” and “cumulative flow diagram” will help you to better understand the bottlenecks in that flow of work and improve it.

The cycle time histogram – with a mean and standard deviation of the cycle time – will lead you towards a probabilistic forecast for when work will be completed.

So you have transparency with the customer on delivery, and also the tools to test any hypothesis you might have regarding improving how work flows within the team.

And of course, you can extend this to an “upstream Kanban” for features, where you (say) develop a feature hypothesis, story map and deliver the feature itself. That leads to even more transparency when it comes to the mid-level *operational* forecasting.

The big difference with Scrum is the lack of a Product Goal, Sprint Goal and the Sprint cadence; that means that the overall product direction and product-market fit is not directly considered as part of the cycle.

The other big difference is that team can cover several product areas, and deal with bugs or defects, as well as technical debt easily. That might make easier if you have a “brownfield” product that lacks automated testing, and are moving to a more agile od DevOps delivery models.

Well, at a point they are not really roles, just a set of accountabilities that someone in the team needs to have – at least by the 2020 Scrum Guide.

At a point there was a reason that these were split out. There’s a degree of tension between the two sets of accountabilities that can lead to a conflict of interest in one individual, and lead towards the more directive, autocratic leadership style that some project managers adopt.

Of course, there’s no obligation to do Scrum, and the Scrum Guide is licenced in a way that allows you to adapt and create your own version (as long as you attribute the authors of the original) so you can really do what you want.

That said, I think it would be quite hard to

a) take care of all of the Product Owner accountabilities for one or more teams and
b) take care of all of the Scrum Master accountabilities across the entire organisation

It’s when the PO role is “owner in name only” and the Scrum Master role is confined to working on a single team without the wider impact, that the roles might shrink enough to be a single person…

Ah – I’d tend to keep the team-level metrics away from any external group; these are things for the team to help improve throughput and delivery, not for high level discussion.

What I tend to show at a high level is a forecast for delivery based on the team’s mean 9and standard deviation) of the throughput.

We’re usually using a “feature level” upstream Kanban for large items. For the initial sizing I tend to get the team to estimate using the Fibonacci scale in sprints/iterations/weeks/months (ie a big time unit). We don’t get to a single figure always, just the range they are 85% confident in.

We then refine that work through story mapping sessions, surfacing assumptions (which can become risks to be managed), as well as unknowns (to be addressed with spikes)

That provides a pretty accurate forecast overall, with a precision that is improved as we

– story map and do spikes to refine the estimates
– do the work get feedback and discover work

It’s certainly enough for meso-scale operational planning (which quarter will X be delivered, do we need to hire more people, do we need to split a feature into parts etc.)

Once you have maybe 30-50 features completed then you’ll have enough data just to use the mean and standard deviation of the feature cycle time for forecasts.

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.