Aaarrrggghhhh. What do I say to a waterfall project manager who demands that we convert our point to time?
So frustrating, their “fake agile” team convert their points to time, so why can’t we? Have explained about a burnup chart, but he wants a gannt chart before we’ve even planned the next increment…
Any and all assistance appreciated.
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.